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Model interoperabilnog elektronskog poslovanja platnih sistema 
zasnovanih na ontologijama 


APSTRAKT: Predmet ove disertacije je razvoj i primena modela interoperabilnog 
elektronskog poslovanja platnih sistema zasnovanog na ontologijama i Resource-Event- 
Agent - REA (ISO/IEC 15944-4:2007) ontološkoj objektnoj strukturi sistema. 
Istraživanje je bazirano na globalnim poslovnim standardima finansijske industrije - 
referentnim modelima za razmenu informacija. Saznanja iz implementacije sistema za 
kliring čekova i sistema za direktno zaduženje u Udruženju banaka Srbije koji su 
realizovani korišćenjem obrazaca za poslovnu integraciju (EIP - Enterprise Integration 
Patterns) i standardizovanih sistema poruka primenjena su u istraživanju. Istraživanje 
je prilagođeno i za implementaciju interoperabilnih platnih sistema u Srbiji. 

Različiti platni sistemi u procesu elektronskog poslovanja su u interakciji sa različitim 
poslovnim sistemima učesnika. Poslovni sistemi učesnika podržavaju veliki broj 
korisnika i poslovnih procesa sa specifičnim zahtevima. Osnovni problem je 
heterogenost između poslovnih procesa, podataka i korišćenih IT tehnologija. Iz tog 
razloga vreme, finansijska sredstva i informatički resursi se troše na prevođenje 
podataka iz jednog sistema u drugi. Razmena finansijskih transakcija elektronskim 
putem postala je prevladavajuća. Time nastaje potreba za razvojem modela 
interoperabilnog elektronskog poslovanja platnog sistema za razmenu finansijskih 
transakcija i njihovu obradu. Standardizacija u domenu modeliranja platnih sistema, 
koja će biti razmatrana, treba da doprinese i većoj efikasnosti ostalih sistema 
elektronskog poslovanja i interoperabilnosti elektronskog poslovanja učesnika. 

U svakoj državi platni sistem se sastoji od skupa platnih instrumenata, bankarskih 
procedura i sistema za prenos sredstava između finansijskih institucija u cilju 
obezbeđivanja cirkulacije novca. Centralna banka neposredno definiše, reguliše i 
usmerava tokove novca i ispunjava svoju osnovnu funkciju regulatora finansijskih 
tokova putem kontrole platnih sistema. Najvažniji je Real Time Gross Settlement Svstem 
- RTGS, sa kojim su hijerarhijski povezani sistemi banaka i drugih finansijskih 
institucija, pravnih i fizičkih lica. Među njima su klirinške kuće, agenti, procesorske 
kuće i zakonom definisane institucije koje se bave izvršenjem, procesiranjem, 
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akvizicijom ili distribucijom informacija o finansijskim transakcijama, ali i drugi 
sistemi elektronskog poslovanja. Platni sistemi, na način opisan u ovom radu, 
objedinjuju elemente koji figurisu u svakom sistemu baziranom na porukama, 
tehnološke elemente nadređenih institucija koji su implicirani standardnim formatom 
poruka, ambijentalne uslove zadate mestom na kome se platni sistem ostvaruje (mesto u 
finansijskoj vertikali, vrsti procesiranja za koje je opredeljen, geopolitičkoj topologiji i 
drugim mogućim elementima), potrebnoj komunikacionoj interakciji, neophodnim 
informacionim tehnologijama za realizaciju pojedinačnih i opštih zadataka. 

Ontologije kao formalni opis objekata, njihovih osobina i odnosa u određenom domenu 
eksplicitno su razumljive i za čoveka i za računar. U ovom radu ontološkim pristupom 
se postiže interoperabilnost i konzistentnost u modelu i obogaćuje dizajn modela sa 
domena znanja. Standard ISO 15944-4:2007, koji je razmatran u rešenju, definiše 
ontološko okruženje za specifikaciju koncepata i relacija uključenih u poslovne 
transakcije i scenarije nazvane Resource-Event-Agent - REA ontologijom. Model je 
primenjen u konkretnom poslovnom okruženju. 

Ključne reči: sistemi zasnovani na porukama, interoperabilnost, elektronsko 
poslovanje, platni sistemi. 

Naučna oblast: Internet tehnologije. 


Uža naučna oblast: Elektronsko poslovanje. 
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The model of interoperable electronic Business of payments systems 

founded on ontologies 

ABSTRACT: The subject of this dissertation is development and application of the 
model of interoperable e-Business of pavment svstems based on ontologies and 
Resource-Event-Agent - REA (ISO/IEC 15944-4:2007) ontological object svstem 
structure. Referential models in the information exchange upon global business 
standards of financial industrv are basis for this investigation. It will applv the 
experience and know!edge from the implementation of the Check Clearing and Direct 
Debit svstems within the Association of Serbian Banks, created by the use of Enterprise 
Integration Patterns (EIP) and the standardized svstems of messages. The investigation 
will be adjusted to the implementation of interoperable pavment svstems in Serbia. 

Various pavment svstems in the process of electronic transaction interact with various 
participants' business svstems. Participants ’ business svstems support a great number 
of users and business processes with specific requirements. In this, the basic problem is 
dissimilaritv between business processes, data and IT technologies. From that reason, 
time, financial, and informatics resources are wasted on the data transfer from one to 
another svstem. Todav, the exchange of financial transactions electronicallv became 
predominant. This calls for the development of models of interoperable e-Business of 
pavment svstems for the exchange of financial transactions and their processing. The 
standardization in the domain of pavment svstem modeling, considered in this studv 
should contribute to greater efficiencv of other electronic business svstems and to 
interoperabilitv of participants ’ electronic businesses. 

In every countrv pavment svstem comprises a number of pavment instruments, banking 
procedures, and the svstems for the fund transfer between financial institutions. That 
alowws the circulation of топеу in the countrv. The Central Bank directlv defines, 
regulates and directs the топеу fiow, and fulfills the function of the regulator of 
financial fiows through the control of the pavment svstems. The most important is Real 
Time Gross Settlement Svstem - RTGS, which for the mentioned reasons, is mainly 
under the supervision of Central Bank. Banks' svstems and the svstems of other 
financial institutions are connecting by RTGS Svstem. Among them there are 
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institutions like clearing houses, pavment agents, processing houses, and other. Thev 
are defined by law, deals with implementation, processing, information acquisition, or 
distribution regarding financial transactions, as we\l as other svstems of electronic 
business. Pavment svstems, on the wyu described in this work, unifv the elements, 
existent in everv svstem based on messages, technological elements of supervising 
institutions, implicated by the standard message format, ambient conditions imposed by 
the place with the implemented pavment svstem (in financial vertical, with kind of 
processing for which it is committed, geo-political tvpologv, and other possible 
elements), required communicational interaction, information technologies necessarv 
for realization of general and specific tasks. 

Being formal descriptions of objects, their characteristics and relationships in a 
particular domain, ontologies are ехрНсМу understandable for man and computer. In 
this work, the ontological approach grants interoperabilitv and consistencv in model 
and enriches the design of the model from the domain of knowledge. Standard ISO 
15944-4:2007, which will be considered in this studv, defines ontological background 
for the specification of the concepts and relations included in the business transactions 
and scenarios known as Resource-Event-Agent - REA ontologv. 

Кеу words: Message based svstems, interoperabilitv, electronic business, pavment 
svstems. 

Scientific area: Internet Technologies. 


Field of Scientific area: E-Business. 
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1 Uvod 

1.1 Deflnisanje predmeta istraživanja 

Predmet ove disertacije je razvoj i primena modela interoperabilnog elektronskog 
poslovanja platnih sistema zasnovanog na ontologijama i REA (ISO/IEC 15944-4:2007) 
ontološkoj objektnoj strukturi sistema. Istraživanje je bazirano na globalnim poslovnim 
standardima finansijske industrije - referentnim modelima za razmenu informacija. 
Saznanja iz implementacije sistema za kliring čekova i sistema za direktno zaduženje u 
Udruženju banaka Srbije koji su realizovani korišćenjem obrazaca za poslovnu 
integraciju ( EIP - Enterprise Integration Patterns) i standardizovanih sistema poruka će 
biti primenjena u istraživanju. Istraživanje biće prilagođeno za implementaciju 
interoperabilnih platnih sistema u Srbiji. 

Ontologije kao formalni opis objekata, njihovih osobina i odnosa u određenom domenu 
su eksplicitno razumljive i za čoveka i za računar. Ontološkim pristupom se postiže 
interoperabilnost i konzistentnost u modelu i obogaćuje dizajn modela sa domena 
znanja. Standard ISO 15944-4:2007, koji će biti razmatran u rešenju, definiše ontološko 
okruženje za specifikaciju koncepata i relacija uključenih u poslovne transakcije i 
scenarije nazvan e Resource-Event-Agent (REA) ontologijom. 

Korišćenje poruka ( Messaging ) ima važnu ulogu na nivou razmene podataka, odražava 
se na aplikativne modele sistema i operacije u sistemu izazvane događajem. Na nivou 
razmene poruka transportni mehanizam omogućava korišćenje posebnih modula za 
razmenu poruka i njihovu obradu. Upotrebom sistema za razmenu poruka, u rešenju 
koje će biti razmatrano, ostvaruje se pouzdanost u komunikaciji, transparentnost u 
odnosu na programske jezike i platforme, postiže se asinhronost koja omogućava 
modulima nezavisnost obavljanja operacija bez gubljenja vremena na čekanje izvršenja 
operacija drugih modula. Postiže se mogućnost podešavanja vremena obrade u odnosu 
na kapacitete, odstranjuju se zaglušenja i onemogućavanje rada modula prouzrokovanih 
prevelikim brojem poziva operacija modula. 

Interoperabilnost se postiže korišćenjem standardizovanih sistema poruka i transportnih 
sistema za njihovu razmenu i omogućava učesnicima standardan pristup operacijama sa 
finansijskim transakcijama. Razmena finansijskih transakcija se odvija na nivou 
klirinških kuća, centralne banke, banaka i drugih finansijskih organizacija, organa 
državne uprave, organizacija na nivou državnih zajednica, na međunarodnom nivou, 
kao i privrednih subjekata i građana koji se javljaju kao učesnici u platnim sistemima. 
Svima njima je potrebno da mogu na lak način razmeniti finansijske transakcije koje 
opisuju korišćenjem istih meta podataka, a koje prate podatke tokom procesa njihovog 
nastanka, prikupljanja, razmene i obrade. Koordinacija između učesnika u platnom 
prometu unutar države jeste suštinska za postizanje konzistentnosti i efikasnosti 
elektronskog poslovanja i postiže se standardizacijom na svim nivoima. Upotreba 
globalnih finansijskih standarda u domenu platnih sistema unapređuje konzistentnost i 
efikasnost elektronskog poslovanja i doprinosi unapređenju sistema za elektronsko 
poslovanje i drugih sistema jer svaka poslovna transakcija elektronskog poslovanja ima 
kao rezultat jednu ili više finansijskih transakcija. Glavni faktor uspešne implementacije 
platnih sistema na državnom i međunarodnom nivou predstavlja uspostavljanje 
višeslojne interoperabilnosti elektronskog poslovanja u skladu sa globalnim 
standardima. Obaveza Narodne banke Srbije je stvaranje mogućnosti za elektronsku 
razmenu finansijskih transakcija između svih učesnika i to je preduslov za realizaciju 
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ovog i drugih sistema za elektronsko poslovanje, u cilju približavanja EU i članstvu u 
toj organizaciji. 

Različiti platni sistemi u procesu elektronskog poslovanja su u interakciji sa različitim 
poslovnim sistemima učesnika. Poslovni sistemi učesnika podržavaju veliki broj 
korisnika i poslovnih procesa sa specifičnim zahtevima. Osnovni problem je 
heterogenost između poslovnih procesa, podataka i korišćenih IT tehnologija. Iz tog 
razloga vreme, finansijska sredstava i informatički resursi troše se na prevođenje 
podataka iz jednog sistema u drugi. Razmena finansijskih transakcija elektronskim 
putem postala je prevladavajuća. Time nastaje potreba za razvojem modela 
interoperabilnog elektronskog poslovanja platnog sistema za razmenu finansijskih 
transakcija i njihovu obradu. Standardizacija u domenu modeliranja platnih sistema, 
koja će biti razmatrana, treba da doprinese i većoj efikasnosti ostalih sistema 
elektronskog poslovanja i interoperabilnosti elektronskog poslovanja učesnika. 

Model interoperabilnog elektronskog poslovanja platnog sistema je skup obrazaca koji 
omogućavaju da strukture platnog sistema zasnovanog na ontologijama mogu 
perzistirati u relacionom modelu podataka koji sledi iz standardizovanih XML šema 
podataka. 

Registraciono telo koje se predlaže u ovom radu ima zadatak da arhivira poruke i 
potvrde prijema i na taj način za treća lica, na specijalan zahtev, recimo potrebe 
veštačenja, učini poslovne procese elektronskog poslovanja sledljivim i neporecivim. 

Sistemi Kompanije Dunav osiguranja, Dunav banke, Dunav auta i Udruženja banaka 
Srbije biće realan sistem za analizu, istraživanje i primenu modela predloženog u ovoj 
disertaciji. 

Realizacija će se odvijati u sledećim pravcima: 

• istraživanje postojećih modela platnih sistema, klasifikacija prema: načinu 
plaćanja, mestu plaćanja, veličini transakcija, načinu obračuna, instrumentima 
plaćanja, modelu plaćanja, platnim servisima,poslovnom modelu plaćanja, 
korišćenim IT i komunikacionim tehnologijama i njihova primena u sistemima 
elektronskog poslovanja; 

• istraživanje postojećih metoda interoperabilnosti i istraživanje mogućnosti 
njihove primene u sistemima elektronskog poslovanja; 

• istraživanje mogućnosti modeliranja interoperabilnog modela zasnovanog na 
ontologijama; 

• istraživanje mogućnosti razvoja modela za generisanje, razmenu i obradu 
finansijskih transakcija, integraciju i prihvatanje informacija iz distribuiranih, 
heterogenih izvora podataka korišćenjem obrazaca za poslovnu integraciju; 

• modelovanje arhitekture platnih sistema zasnovane na obrascima za poslovnu 
integraciju; 

• istraživanje mogućnosti za automatsko uspostavljanje interoperabilnosti u okviru 
poslovnih procesa platnih sistema; 

• prikaz i analiza koncepata vezanih za REA; 

• implementacija interoperabilnog modela platnog sistema zasnovanog na 
ontologijama 

• merenje perfonnansi po izabranim kriterijumima. 
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Tokom rada na ovoj disertaciji koristiće se dostupni standardi, saznanja, alati i metode 
vezane za modelovanje interoperabilnosti elektronskog poslovanja kod platnih sistema i 
primena ontologija na razvoj modela interoperabilnog platnog sistema. 

1.2 Ciljevi istraživanja 

Osnovni cilj istraživanja je razvoj modela interoperabilnog elektronskog poslovanja u 
platnim sistemima, zasnovanog na ontologijama finansijskih transakcija u platnim 
sistemima i ontološkim modelima. Istraživanje će obuhvatiti tehnike i metode za 
kreiranje ontologija elektronskog poslovanja, modela poslovnih procesa kao i 
mogućnost za razvoj okvira interoperabilnosti sa drugim sistemima po istim principima 
u slučajevima, kada odvijanje aktivnosti procesa izlazi iz granica jednog sistema i 
prelazi u drugi. 

Cilj istraživanja je i unapređenje i poboljšanje performansi servisa elektronskog 
poslovanja platnih sistema: kvaliteta, troškova, prilagodljivosti, potražnje, brzine i 
inovativnosti servisa. 

Interakcija sistema elektronskog poslovanja u ovim slučajevima može se postići 
koristeći iste principe integracijom standardizovanih komponenata sistema, koje su 
neophodne za kompletiranje svih aktivnosti procesa, predviđajući unapred potrebne 
integracije kada je to i moguće. Postojeći okviri za uspostavljanje interoperabilnosti 
sistema koristiće sisteme poruka ( Messaging ) u odgovarajućoj arhitekturi poslovne 
integracije. 

Suštinski koncept razmene sistema poruka je standardizovanje složenih poslovnih 
procesa u skup asinhronih, nezavisnih procesa koji omogućavaju različite, lake za 
definisanje, implementaciju i sprovođenje, jednostavne poslovne funkcionalnosti. Jedna 
od ideja ovog rada jeste da se princip asinhronih i povezanih procesa može primeniti na 
informacione modele da bi se savladala složenost elektronskog poslovanja u različitim 
platnim sistemima. 

Prema ovom principu, opšti cilj ove teze je da razvije model koji doprinosi smanjenju 
složenosti pri definisanju, implementaciji i korišćenju integrisanih platnih sistema u 
procesu elektronskog poslovanja. 

S obzirom na postavljene ciljeve, zadaci istraživanja su: 

• analiza problema na polju razvoja ontološkog modela platnog sistema; 

• analiza problema na polju interoperabilnosti elektronskog poslovanja platnih 
sistema; 

• istraživanje globalnih standarda finansijske industrije vezanih za zadavanje i 
modeliranje poslovnih procesa platnih sistema, sa osvrtom na oblasti koje nisu u 
potpunosti pokrivene postojećim standardima i specifikacijama; 

• istraživanje postojećih modela interoperabilnosti platnih sistema; 

• analiza standarda za ontološku predstavu modela platnih sistema; 

• razvoj metamodela za unifikaciju organizacije podataka; 

• razvoj metamodela poslovnih procesa platnih sistema zasnovanih na 
standardizovanoj arhitekturi; 
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• razvoj okvira interoperabilnosti elektronskog poslovanja platnih sistema; 

• verifikacija razvijenog okvira interoperabilnosti elektronskog poslovanja platnih 
sistema, modela poslovnih procesa i standardizovanog modela organizacije 
podataka. 

1.3 Polazne hipoteze 

Polazeći od predmeta rada, postavljenih ciljeva i zadataka, može se postaviti glavna 
hipoteza: 

Modelom interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na 
ontologijama moguće je unaprediti razvoj platnih sistema koji je prilagođen uslovima u 
Republici Srbiji. Model treba da bude zasnovan na standardizovanom ontoloskom 
modelu podataka i procesa u poslovno orjentisanoj arhitekturi. 

Pomoćne hipoteze: 

• Primenom predloženog modela može se realizovati interoperabilno elektronsko 
poslovanje platnih sistema u Republici Srbiji; 

• Predloženi model je efikasniji u poređenju sa postojećim modelima integracije; 

• Implementacijom predloženog modela smanjuju se troškovi i povećava se 
pouzdanost elektronskog poslovanja platnih sistema u Republici Srbiji; 

• Uvođenje registracionog tela za registraciju poruka, potvrda prijema i 
verifikaciju poslate poruke i potvrde prijema čini poslovne procese elektronskog 
poslovanja globalno sledljivim i neporecivim. 

1.4 Metodologija istraživanja 

Tokom izrade ovog rada od opštenaučnih metoda koristiće se: modelovanje, strukturna 
analiza, funkcionalna analiza, komparativna metoda, metoda analogije, merenje i metod 
naučnog posmatranja i eksperimenta. Modelovanje će se koristi prilikom izrade modela 
interoperabilnog elektronskog poslovanja platnih sistema. Strukturna analiza, 
funkcionalna analiza, komparativna i metoda empirijskog istraživanja koristiće se 
prilikom analize postojećih rešenja integracije platnih sistema, kao i procesa platnog 
prometa tokom eksperimenta. Merenje relevantnih parametara i analiza dobijenih 
rezultata biće obavljeni pomoću standardnih statističkih metoda. U eksperimentalnom 
delu posmatraće se performanse elektronskog poslovanja platnih sistema kada se 
odvijaju pomoću IT infrastrukture zasnovane na standardizovanom ontološkom modelu 
podataka i procesa u poslovno orjentisanoj arhitekturi. Dobijeni rezultati eksperimenta 
treba da potvrde generalnu hipotezu o postizanju interoperabilnosti u elektronskom 
poslovanju na razvijenom ontološkom modelu platnog sistema dobijenog 
standardizacijom organizacije podataka i procesa platnih sistema. 

Rezultati istraživanja biće prezentovani tekstualno, opisivanjem i prikazom kroz tabele, 
slike i dijagrame sa uporednim rezultatima. Istraživanje će biti interdisciplinarno jer 
uključuje naučne discipline metodologiju, infonnatiku, finansije i druge. Metode 
logičkog objašnjenja koje će se koristiti: metoda analize i sinteze, induktivno i 
deduktivno zaključivanje. Doktorska teza će obuhvatiti odgovarajuće grafičke prikaze i 
prezentacije. 
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Istraživanja predložena u ovoj disertaciji obuhvatiće: metodologiju, alate i standarde 
modelovanja interoperabilnih platnih sistema zasnovanih na ontologijama. 

Studija slučaja u okviru ove disertacije ima za cilj da demonstrira predloženi model 
platnog sistema zasnovan na ontologijama za generisanje, razmenu i obradu finansijskih 
transakcija. 

1.5 Struktura i organizacija rada 

U okviru uvoda opisani su predmet, ciljevi disertacije, polazne hipoteze, metodologija 
istraživanja i struktura rada. 

U drugom poglavlju dat je kratak osvrt na pojam elektronskog poslovanja i značaj 
infonnacionih tehnologija u elektronskom poslovanju sistema. Definisan je koncept, 
nivoi i opšti okvir interoperabilnosti. Naglašena je važnost rešavanja problema 
interoperabilnosti elektronskog poslovanja platnih sistema. Dat je značaj standarda za 
interoperabilnost i ograničenja. Opisani su savremeni trendovi u tehnološkom progresu, 
uticaj razvoja informacionih tehnologija i zakonodavni okvir elektronskog poslovanja 
kao i prikaz elektronskog poslovanja platnih sistema u svetu i kod nas. U ovom 
poglavlju prikazane su i prednosti elektronskog poslovanja i mogućnosti primene 
servisno orijentisane arhitekture za realizaciju rešenja integracije, sa ciljem da se 
podigne nivo interoperabilnosti i ekonomičnosti poslovnih subjekata elektronskog 
poslovanja platnih sistema. Razmatran je i aspekt sigumosti i sigumosnih standarda u 
elektronskom poslovanju. 

U trećem poglavlju dat je pregled platnih sistema, od osnovnih definicija i klasifikacija 
finansijskih organizacija do opisa multikanalnih sistema pravnih i fizičkih lica. Opisani 
su standardi platnih sistema i sistema za razmenu pomka. Naglašeni su i globalni 
standardi i način na koji se oni zadaju i prezentuju u globalnoj finansijskoj zajednici. 
Prikazani su i relevantni platni sistemi u svetu, u državama našeg okmženja a 
razmatrana je i zakonska regulativa i pregled platnih sistema za plaćanja na malo i 
veliko u Srbiji. Posebno je dat osvrt na način na koji centralna banka vrši nadgledanje 
platnih sistema i na koji način funkcioniše i kao operater platnih sistema kod nas. 

U četvrtom poglavlju dat je pregled relevantnih tehnologija, gde posebno mesto 
zauzimaju XML tehnologije sa standardima za zadavanje podataka i metapodataka 
korišćenjem XML i RDF stmktura. Prikazane su i relevantne stmkturalne i objektne 
metodologije razvoja sa prikazom metoda i paradigmi u razvoju informacionih sistema. 
Opisana je servisno orijentisana arhitektura i veb-servisi kao osnov za izgradnju SOA. 
Posebna pažnja posvećena je proučavanju veb-servisa sa svojom arhitekturom i 
elementima sigurnosti informacionih sistema koji su zasnovani na servisno orijentisanoj 
arhitekturi i veb-servisima. Opisana je uloga semantičkog veba sa ontologijama u 
realizaciji semantičke interoperabilnosti i primena ontologija u integraciji sistema. 

U petom poglavlju, koje predstavlja najznačajniji naučni doprinos ove disertacije, 
opisan je razvoj modela interoperabilnog elektronskog poslovanja platnih sistema 
zasnovanog na ontologijama. Definisana je stmktura modela i softverska arhitektura 
predloženog sistema integracije. Opisana je metodologija razvoja modela, razvijen je 
model zasnovan na servisno orijentisanoj arhitekturi, integraciji informacija i aplikacija 
korišćenjem ontologija. Dat je prikaz procesa elektronskog poslovanja platnog sistema, 
opisana je stmktura modela podataka i model procesa koji se potvrđuju prikazanim 
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matematičkim modelom. Kreirana je domenska ontologija i opisan je metod razvoja 
elektronskog poslovanja platnih sistema zasnovan na ontologijama i način identifikacije 
komponenata modela, kao i metode integracije koje obezbeđuju interoperabilnost 
elektronskog poslovanja platnih sistema na nacionalnom i međunarodnom nivou. 

U šestom poglavlju prikazana je implementacija osnovnom arhitekturom predloženog 
generičkog modela poslovnih procesa elektronskog poslovanja platnih sistema, opisom 
aktivnosti razvoja sistema, funkcionalnosti i prikazanim projektnim zahtevima koje 
sistem mora da zadovolji. Definisana je struktura modela i logička i fizička arhitektura 
predloženog sistema integracije. Predstavljane su aktivnosti, scenariji i mehanizmi 
integracije. Izvršena je analiza postavljenih zahteva sistema za razmenu podataka i 
servisa za procesiranje, opisan je i analiziran referentni model i prikazano uspostavljanje 
interoperabilnosti poslovanja elektronskog poslovanja različitih sistema elektronskog 
poslovanja i elektronskog poslovanja platnih sistema sa lancima snabdevanja, sistema 
osiguravajućeg društva, registracionog tela i klirinške kuće, kao i izvršeni eksperiment u 
konkretnom okruženju. Izvršena je analiza rezultata koji pokazuju da se primenom 
razvijenog modela integracije omogućava interoperabilnost elektronskog poslovanja 
platnih sistema na nivou: podataka, servisa, poslovnih procesa i na semantičkom nivou. 
Predloženo rešenje prevazilazi konceptualne, tehnološke i organizacione prepreke 
interoperabilnosti elektronskog poslovanja platnih sistema. Primenom predloženog 
rešenja integracije podiže se nivo efikasnosti i ekonomičnosti elektronskog poslovanja 
platnih poslovnih sistema. 

U sedmom poglavlju dat je pregled naučnih i stručnih doprinosa disertacije. Budući 
pravci istraživanja prikazani su u osmom poglavlju. U zaključku je dat pregled sadržaja 
i naučnih doprinosa disertacije. Spisak literature sadrži relevantne reference za oblast 
disertacije. U prilogu su dati spisak slika i tabela iz disertacije, operativna pravila sa 
pratećom dokumentacijom koju je autor disertacije definisao sa tehnolozima Udruženja 
banaka Srbije, regulativa evropskog saveta za plaćanja i finansijski proračun godišnjih 
finansijskih prihoda od procesiranja klirinške kuće. Na kraju rada data je biografija 
autora. 
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2 Elektronsko poslovanje 

U ovom poglavlju dato je objašnjenje pojmova elektronskog poslovanja i 
interoperabilnosti. Opisane su komponente sistema i okruženje elektronskog poslovanja, 
kao i to kako globalni tehnološki progres i razvoj infonnaciono komunikacionih 
tehnologija utiče na razvoj elektronskog poslovanja. Objašnjeni su konteksti 
elektronskog poslovanja i organizacione promene koje su nastale uvođenjem 
elektronskog poslovanja, kao i napori na polju standardizacije i zaštite elektronskog 
poslovanja. 

2.1 Defmicija elektronskog poslovanja 

Razvoj informaciono - komunikacionih tehnologija i globalne ekonomije stvorio je 
uslove za globalizaciju poslovanja. Model globalne organizacije i jake konkurencije 
zahteva odgovarajuću koncepciju pristupa organizacija poslovanju, o čemu svedoči 
uvećano ulaganje u tehnologiju orijentisanu prema klijentu [75]. Integracijom velikog 
broja informacionih sistema i mreža, internet tehnologije su potpuno otvorile vrata 
konceptu elektronske ekonomije time što su omogućile kreiranje inovativnih poslovnih 
pristupa u domenu prodaje, kupovine i intemom kreiranju poslovnih procesa. 
Usmerenost savremenog poslovanja organizacija ka globalnom tržištu podrazumeva 
integrisanost informacionih i komunikacionih tehnologija, kojima se obezbeđuje protok 
podataka bez prostomih ograničenja. 

Primenom koncepta savremenog poslovanja i integracijom savremenih tehnologija u 
poslovanju dolazi do promena poslovanja u odnosu na okmženje ali istovremeno i 
unutar same organizacije. Informacija dobija mesto nezaobilaznog elementa, pored 
proizvoda, usluga i novca u stmkturi tržišta. Domen promena se značajno menja 
razvojem globalne informatičke infrastmkture kao podrške u realizaciji uobičajenih 
svakodnevnih zadataka i prilikom donošenja strategijskih odluka organizacije, 
odražavajući se na uspešnost organizacije u poslovnom okmženju. Uspešnost 
poslovanja organizacije zavisi od pronalaženja mesta u globalnoj podeli rada čime se 
postaje deo globalnih poslovnih procesa. Razvoj Interneta omogućio je jednostavnu i 
brzu komunikaciju, mogućnost prenošenja velike količine podataka na velike 
udaljenosti, kontinuiranu i globalnu dostupnost sadržaja. Elektronsko poslovanje je 
opšti koncept koji obuhvata sve oblike poslovnih transakcija ili razmene informacija 
koje se izvode korišćenjem informacione i komunikacione tehnologije i to: između 
organizacija, između organizacija i njihovih klijenata i između organizacija i javne 
administracije. Elektronsko poslovanje se može posmatrati sa više stanovišta: Sa 
aspekta komunikacija elektronsko poslovanje je elektronska ispomka infonnacija, 
proizvoda, usluga i elektronsko plaćanje. Sa poslovnog aspekta te je primena 
tehnologije u svrhu automatizacije poslovnih transakcija i poslovanja. Sa stanovišta 
usluga to je alat koji omogućava smanjenje troškova poslovanja uz povećavanje 
kvaliteta i brzine pmžanja usluga [198]. 

Jedna od najpotpunijih definicija elektronskog poslovanja data je u radu [212], gde se 
elektronsko poslovanje definiše ne samo kao kupovina i prodaja robe i servisa, već i kao 
servisiranje klijenata, saradnja u poslovnim procesima sa poslovnim partnerima ali i 
obavljanje elektronskih transakcija u organizaciji. Elektronsko poslovanje je opšti 
koncept koji obuhvata sve oblike poslovnih transakcija ili razmene informacija koje se 
izvode korišćenjem informacione i komunikacione tehnologije između poslovnih 
organizacija ili unutar same organizacije. 
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Začeto je prvim razmenama elektronskog sadržaja šezdesetih godina prošlog veka. 
Početkom sedamdesetih godina ustanovljavaju se čvrsti koreni elektronskog poslovanja 
nastankom elektronskog prenosa gotovine (EFT - Electronic Fund Transfer ), koji se 
odvijao između banaka putem sigumih privatnih mreža. Osamdesetih godina razvijena 
su dva nova oblika elektronskog poslovanja: elektronska razmena podataka (EDI - 
Electronic Data Interchange ) i elektronska pošta, koji su smanjili obim potrošnje i 
cirkulacije papira i automatizacije dela poslovanja. EDI je omogućio elektronsku 
razmenu dokumenata u standardnom elektronskom obliku. Bio je skupa tehnologija 
koju su mogle da koriste samo najveće organizacije. Mala preduzeća su koristila onlajn 
servise sa aplikativnim slojem koji je omogućavao elektronsku razmenu podataka. 
Originalni koncept elektronskog poslovanja nastao je krajem devedesetih godina 
prošlog veka. Pojam elektronskog poslovanja sredinom devedesetih godina prošlog 
veka dcfinisao je prvi IBM opisujući ga kao delatnost koja omogućava izgradnju i 
primenu poslovnog modela u kome se organizaciona stmktura menja zavisno od 
poslova, a model poslovanja se oslanja na informatičke stmkture i visok nivo 
automatizacije, što doprinosi optimizaciji poslovnih procesa i sticanju prednosti nad 
konkurencijom. Pokrenute su različite dmge inicijative koje su doprinele da se 
originalni koncept elektronskog poslovanja podigne na viši nivo, odnosno elektronsko 
upravljanje poslovnim procesima korišćenjem informaciono-komunikacionih 
tehnologija za vođenje i unapređenje poslovnih procesa [120]. Elektronsku ekonomiju 
danas reprezentuju tri bitne komponente: infrastmktura kao podrška elektronskom 
poslovanju, elektronski poslovni procesi kao način na koji se realizuje poslovanje i 
transakcije elektronske trgovine, odnosno prodaja i kupovina. 

2.1.1 Prednosti elektronskog poslovanja 

Postoje brojne prednosti automatizacije poslovanja koje uključuju: porast operacijskih 
delovanja, merljivi porast produktivnosti, smanjeno vreme procesa, skladan kvalitet 
proizvoda i usluga zahvaljujući pravoj kontroli procesa, smanjenje troškova kroz 
eliminaciju papirologije i ,,mčnih“ procesa, neposredan tok informacija između 
zaposlenih i poslovnih partnera, povećanje zadovoljstva zaposlenih i zadovoljstva 
poslovnih partnera. Kao osnovne prednosti elektronskog poslovanja izdvajaju se [198]: 

• jednostavan i jeftin izlaz ka poslovnom okmženju; 

• efikasno održavanje komunikacije sa poslovnim partnerima; 

• automatizacijaprocesa; 

• povećanje broja poslovnih transakcija; 

• bolj a optimizacij a poslovanj a; 

• smanj enj e grešaka, pogotovu gde j e tačnost infonnacij a od značaj a; 

• ušteda vremena, posebno u prenosu informacija; 

• pristupačnost i razmenljivost informacija; 

• drastično smanjenje troškova obrade; 

• smanjenje obima ljudskog rada; 

• smanjenje troškova poslovanja uštedom na smanjenju papime dokumentacije; 

• smanjenje troškova poslovanja uštedom na putnim i dmgim sličnim troškovima; 

• ekološki aspekti smanjenjem štampe i putovanja; 

• niži troškovi plasiranja proizvoda i usluga na tržište koji rezultiraju nižim 
prodajnim cenama i većom konkurentnošću; 

• dostupnost na globalnom nivou 24 časa tokom svih sedam dana u nedelji; 
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• mala ulaganja u IT da bi se obezbedila prisutnost u poslovnom ambijentu. 

Elektronsko poslovanje često je prožeto i problemima uzrokovanim neslaganjima 
između materijalnih i informacionih tokova. Nedostatak vidljivosti i informacionih 
tokova u vezi sa statusom elektronske poslovne transakcije porudžbine može da izazove 
nesigumost i promenljivost u elektronskom poslovanju. Najveći nedostaci elektronskog 
poslovanja su: 

• izostanak socijalnog aspekta klasičnog poslovanja; 

• suviše veliki intenzitet promena tehnologija; 

• problemi bezbednosti; 

• pojava novih tehničkih problema sa svojim rizicima; 

• međunaro dne b arij ere; 

• kulturološke prepreke. 

2.2 Komponente sistema elektronskog poslovanja 

Elektronsko poslovanje je opšti koncept koji obuhvata sve oblike poslovnih transakcija 
ili razmene infonnacija koje se izvode korišćenjem informacione i komunikacione 
tehnologije. Tumačenje i razumevanje ovog pojma svakodnevno se menja, a načelno 
treba da obuhvati složenost poslovanja jer obuhvata generisanje i održavanje evidencija 
kupaca i partnera, da integriše digitalnu komunikaciju, e-trgovinu, onlajn istraživanja, 
primenu svake vrste poslovanja i aktivnosti putem mreže, prikazano na slici 1. 



Slika 1. Uprošćcna slika elektronskog poslovanja 

Osam segmenata okmžuje klijenta kao polaznu osnovu svih savremenih poslovnih 
procesa [204]: strategija elektronskog poslovanja, e-marketing, ljudski resursi, pravo i 
zaštita, e-trgovina, lanci snabdevanja, veb-dizajn i veb-tehnologija. Osnovni cilj 
poslovnih koncepcija jeste zadovoljenje potreba klijenata i formiranje poslovnog 
okruženja u organizaciji tako da svi poslovni procesi budu u funkciji potreba klijenta, a 
da se kao rezultat kvalitetnih odnosa s klijentima pojavi profit. 

Strateški segmenti elektronskog poslovanja sastoje se od e-filozofije, strategije i 
politike, e-marketinga, odnosa sa javnošću i informaciono-komunikacione 
infrastrukture. Elektronsko poslovanje se odvija u distribuiranom okruženju Intemeta, 
gde je cilj ostvariti odabrani, najčešće visoki nivo interaktivnosti s klijentom. E- 
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marketing je strateško odlučivanje o poslovnim procesima u cilju zadovoljenja potreba 
korisnika i organizacije, a zasniva se na kreiranju baza znanja o profilu i potrebama 
kupaca, osoblja organizacije, menadžmenta i ostalih ciljnih elemenata u poslovnom 
okruženju organizacije. 

Operativni segmenti elektronskog poslovanja sastoje se od e-proizvodnje, e- 
tehnologije, e-distribucije, e-zaštite i prava. E-proizvodnja se odvija u distribuiranom 
okruženju, koje obezbeđuje rad na daljinu. Internet takođe omogućuje upravljanje 
kvalitetom proizvoda koji su kreirani na osnovu potreba korisnika u realnom vremenu. 
E-tehnologija postoji da bi se ostvario sistem efikasnog i isplativog elektronskog 
poslovanja. Organizacija mora da poseduje određenu informacionu i komunikacionu 
infrastrukturu, da ima opisane poslovne procese na nivou upravljanja bazama podataka i 
da strateški i operativno koristi podatke iz informacionog sistema za upravljanje na 
različitim hijerarhijskim nivoima odlučivanja. E- tehnologije su one koje omogućuju 
ostvarenje poslovnih procesa, od nivoa veb-softverske tehnologije, dizajna i njihove 
upotrebljivosti na nivou potreba korisnika. One obuhvataju i procese razmene između 
zainteresovanih strana u poslovnom procesu u zavisnosti od tipa e-poslovanja (B2C, 
B2B, B2E, B2G, C2G) [124]. E- distribucija služi da bi se uspešno završio proces 
razmene dobara između zainteresovanih strana u procesu onlajn poslovanja, odnosno 
obezbedili prilagođeni modeli lanaca distribucije fizičkih i nematerijalnih dobara i 
usluga. 

Da bi kompletan proces on-line poslovanja bio uređen i u skladu sa potrebama 
zainteresovanih strana, mora postojati pravni okvir koji osigurava bezbedno poslovanje 
sa maksimalno smanjenim rizicima, odnosno e-zaštita. 

E-trgovina (i e-commerce ) predstavlja kupovinu i prodaju dobara ili usluga putem 
Intemeta kao i prihode od reklame, elektronsku razmenu dokumenata koji prate robu, 
novac i usluge putem elektronskih sredstava. Ovaj proces uključuje kako maloprodajne, 
tako i veleprodajne transakcije. Elektronska trgovina se ispoljava preko njenih fonni i 
modela. Osnovni modeli elektronske trgovine su kupovina iz izloga, portal, dinamičko 
formiranje cena i onlajn kupovina i model pozajmice, a fonne B2B, B2C, C2C i dmge. 

Upravljanje odnosima sa klijentima ( Customer Relatioship Management - CRM) 

predstavlja skup poslovnih procesa i tehnologija za upravljanje relacijama sa postojećim 
i potencijalnim korisnicima i poslovnim partnerima u marketingu, prodaji i podršci, 
preko svih raspoloživih kanala komunikacije. Ona podrazumeva sve aspekte interakcije 
kompanije sa klijentima, bez obzira na to da li se radi o prodaji ili uslugama, 
podrazumeva personalizaciju poslovanja sa svakim klijentom pojedinačno. CRM mora 
biti integrisan u celokupan proces od inicijalnog kontakta do krajnje kupovine, a 
marketing, prodaja i odeljenje podrške korisnicima moraju biti integrisani putem 
informacione tehnologije. 

Planiranje resursa preduzeća ( Enterprise Resource Planning - ERP) rešenja 
objedinjuju module finansija, logistike i proizvodnje. Najkraće rečeno, to je softverski 
paket koji prati sve aspekte poslovanja jedne kompanije. Jedna od definicija ERP 
sistema kvalifikuje softversko rešenje u ERP kategoriju ako zadovoljava sledeće uslove: 
efektivno upravljanje procesima u preduzeću, postojanje zajedničke (jedinstvene) baze 
podataka, mogućnost da se reaguje brzo na operativne zahteve. hnplementirani ERP 
sistem je u mogućnosti da integriše poslovanje različitih delova firme (npr. 
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računovodstvo, proizvodnju, nabavku, prodaju itd.) u jednu jedinstvenu celinu. Tako se 
dobija sistem preko koga je moguće upravljati svim ljudskim i materijalnim resursima, 
kao i planirati, razvijati i pratiti poslovne procese i procedure. 

Upravljanje lancima snabdevanja (Supply Chain Management - SCM) je termin koji 
se koristi da opiše tok materijala, informacija i sredstava kroz lanac nabavke, od 
snabdevača preko proizvođača pojedinih komponenata, konačnog spajanja i distribucije 
(skladišta i maloprodaja), pa do konačnog kupca. Taj proces često sadrži i dodatne 
usluge koje prate proizvod posle prodaje i povraćaj proizvoda na reciklažu. Lanac 
vrednosti je skup poslovnih procesa koji povezuje snabdevače, proizvođače, prodavce 
na malo, poslovne korisnike i ostale umešane u stvaranje, prodaju i isporuku robe do 
krajnjeg kupca. Lanac vrednosti odgovara mreži kompanija koje rade zajedno i 
koordiniraju svoje akcije prema isporuci proizvoda na tržište. To je dodatna aktivnost 
koja je postala neophodan deo posla da bi se ispunili zahtevi kupaca. 

Poslovna inteligencija (Business Intellignece - BI) predstavlja proces prikupljanja 
raspoloživih internih i značajnih eksternih podataka i njihovo pretvaranje u korisne 
informacije koje pomažu poslovnim korisnicima pri donošenju odluka [193]. Poslovni 
podaci i istraživanja pružaju primarne i naknadne informacije o tržištu, potrošačima, 
konkurenciji i ostalim činiocima poslovanja na osnovu kojih se može definisati 
strategija poslovanja. U dinamičnom poslovnom okruženju kakvo je danas, od ključnog 
značaja za preduzeće jeste da širokom krugu poslovnih korisnika obezbedi efikasan, 
brz, jeftin i jednostavan pristup potrebnim informacijama. Sistem poslovne inteligencije 
integriše podatke iz različitih izvora (transakcione i analitičke baze podataka, datoteke, 
podaci sa veba itd.) u jedinstveni sistem koji korisnicima omogućava da podatke vide u 
formatu koji je za njih najpogodniji, da vrše različite dodatne analize. 

2.3 Okruženje i infrastruktura elektronskog poslovanja 

Ambijentalno okruženje sistema elektronskog poslovanja je multidisciplinarno. 
Osnovne discipline koje mogu da se uvrste u njega su sledeće: informatika, marketing, 
ponašanje klijenata, finansije, ekonomija, upravljanje informacionim sistemima, 
knjigovodstvo, upravljanje, upravljanje ljudskim resursima, poslovno zakonodavstvo, 
robotika, javna administracija i inženjering. 

2.3.1 Tehnološki progres kao osnova razvoja elektronskog poslovanja 

Tehnološki razvoj je glavni pokretač većine procesa globalizacije. Pre objašnjenja o 
posledicama nekoliko tehnološkog razvoja, moramo proći kroz definisanje tehnologije 
kao sociološkog termina, tako da možemo bolje da sagledamo društvenu i političku 
ulogu tehnologije u procesu globalizacije. Tehnologija se može definisati kao skup 
društvenih znanja potrebnih za proizvodnju roba i usluga koji imaju sledeće elemente: 
proizvodnju, znanje, instrumente, mogućnost posedovanja i promene. Tehnologija je 
usko povezana sa proizvodnjom (robe i usluga); tehnologija uvećava našu proizvodnu 
sposobnost. Tehnologija je rezultat intelektualnih aktivnosti i predstavlja vrstu 
intelektualne svojine. Danas je razvijena kroz istraživanje i razvoj institucija, kao deo 
sastavnih aktivnosti univerziteta. Instrumenti poboljšavaju performanse ljudskog tela. 
Instrumenti ukazuju na korišćenje tehnologije od strane ljudskih bića. Instrumenti su 
uglavnom fizički objekti, ali postoje i instrumenti nematerijalne prirode, kao što su baze 
podataka ili algoritmi u kompjuterskom programiranju i slično. Osobe ili organizacije 
koje poseduju tehnologiju u mogućnosti su i da je kontrolišu i na taj način utiču na 
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ekonomiju i politiku. Iz tog razloga možemo govoriti o tehnološki bogatim i siromašnim 
zemljama i borba je najčešće u formi pridobijanja patenata, transfera i zaštite 
intelektualnih prava. Tehnologija je usko povezana sa promenama. Na primer, 1957. 
obeležen je najvažniji korak u istoriji globalizacije, kada je SSSR lansirao Sputnjik. 
Sateliti su omogućili izgradnju potpuno pouzdane globalne mreže. Digitalne tehnologije 
otvorile su put ka globalnim mrežama. Globalni mreže su mreže u kojoj su sve 
infonnacije i znanje - i ideološki neophodno za realizaciju, održavanje i reprodukciju 
sistema. Monopolizacija ekonomske moći takođe je u vezi sa tehnologijom. Elektronsko 
bankarstvo je u srcu globalnog sistema mreža. Elektronski prenos sredstava (Electronic 
Found Transfer - EFT), prvi je operativni oblik globalnih elektronskih finansijskih 
mreža. EFT je omogućio slanje i primanje finansijskih sredstava među bankama. 
Godine 1973. u Briselu, uz podršku 239 banaka u 15 zemalja, SWIFT [210] počinje 
misiju stvaranja zajedničkog globalnog sistema za obradu podataka i komunikacionih 
veza i zajedničkog standarda za međunarodne finansijske transakcije. Godine 1977, 
Albert, princ Belgije, šalje prvu SWIFT poruku. Do tog vremena inicijalna grupa 
članova je porasla na 518 komercijalnih banaka u 17 zemalja. Do kraja te godine, 
SWIFT ima 518 klijenata u 22 zemalja sa 3.400.000 poruka. Između SAD i Evrope 
1985. uspostavljena je satelitska veza. Uz korišćenje satelitske tehnologije SWIFT se 
vrlo brzo razvijao, pa je do kraja 1999. SWIFT imao 6.797 aktivnih korisnika u 189 
zemalja i dostigao 1.059.000.000 poruka. Danas, na primer, 15.11.2012. procesirano je 
oko 18 miliona FIN (Financial INstitutions) poruka, ukupno do 15.11.2012 u novembru 
193 miliona, do 15.11. u 2012. godini 4024 mibona, a rast u 2012. godini, u odnosu na 
prošlu godinu je +3.09% [209]. 

2.3.2 Uticaj razvoja informacionih tehnologija na elektronsko poslovanje 

Elektronsko poslovanje je indukovano na sledećim informatičkim resursima: 
korisnicima sistema, kadrovima za planiranje, izgradnju i podršku sistemima po 
odabranoj metodologiji, hardveru i komunikacionoj infrastrukturi, sistemskom i 
aplikativnom softveru, tehnološkim znanjima i organizaciji. Skup elektronskih 
poslovnih sistema sa infonnatičkim resursima nad kojima je indukovano jeste 
infonnatička zajednica. Informatičku zajednicu kao društvo pokreće tehnološki 
napredak u oblasti informaciono-komunikacionih tehnologija. Nov globalni pristup 
utiče na reorganizaciju svetskih razmera političkim promenama, liberalizacijom 
privrede, problemima zdravstva, ishrane i životne sredine i generiše do sada najdublje 
promene u društvu. Razvoj informaciono-komunikacionih tehnologija i mogućnost 
njihove primene u svim sferama društva promovisali su ih kao ključne faktore razvoja 
svakog savremenog društva. Ove tehnologije menjaju način na koji ljudi, poslovni i 
upravljački sistemi komuniciraju, kao i globalni ambijent u kome savremene ekonomije 
i društva rade i razvijaju se. Generalno, svet je u procesu izgradnje nove infrastrukture 
koja briše prostorne barijere i omogućava mobilnost poslovnih sistema. Tržište, tokovi 
kapitala i poslova postaju jedinstveni na svetskom nivou i jednostavno dostupni sa svih 
geografskih pozicija. Pojedini poslovni sistemi kao i državne i lokalne zajednice u celini 
postaju učesnici globalne tržišne utakmice. Pravovremene, sveobuhvatne i tačne 
informacije postale su osnovni upravljački resursi u poslovnim sistemima i institucijama 
društva. Ovi resursi mogu se obezbediti jedino razvojem informacionog društva, koje se 
na taj način nameće kao imperativ u svim zemljama koje žele da osiguraju progres i 
budućnost svojim građanima. 

Razvijene zemlje i ekonomije već se nalaze u procesu transfonnacije ka 
„informacionom društvu“ [221] koje se zasniva na primeni savremenih informaciono- 
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komunikacionih tehnologija, i u kojem su informacije, znanje i ljudski resursi od 
vitalnog značaja. Manje razvijene zemlje moraju aktivno delovati u cilju što bržeg 
uključenja u ove procese jer je to jedini put za njihov razvoj i za bitno poboljšanje 
standarda i kvaliteta života građana, kao i uslov integracije u savremene poslovne 
tokove. Tri vida informaciono-komunikacionih tehnologija u najvećoj meri utiču na 
razvoj, unapređenje i korišćenjeinformacionih sistema: razvoj sistema koji omogućavaju 
obradu velike količine podataka i koji dobijanje rezultata distribuiraju u kratkom 
vremenu; telekomunikacije koje predstavljaju glavnu tehnologiju za razvoja mreža 
velike brzine, bežičnih sistema i satelita, koji omogućavaju direktnu vezu izmeću 
računara i brz prenos svih vrsta podataka širom sveta; inteligentni aplikativni sistemi za 
upravljanje informacionim sistemom, koji je jednostavan za upotrebu i povećava 
efikasnost u radu. 

2.3.3 Uticaj razvoja elektronskog poslovanja na poslovanje 

Najveća promena koja utiče na poslovanje jeste upravo pojava Interneta i svih servisa 
koje Internet omogućuje. Zadatak menadžmenta trgovinskih kompanija jeste upravo da 
prepoznaju sve mogućnosti koje Internet pruža, da se sa njima dobro upoznaju ili da 
uposle dovoljno stručan i obrazovan kadar koji će znati da adekvatno upotrebljava već 
postojeća sredstva, a što je najvažnije, koji će biti spreman za konstantno učenje i 
prilagođavanje novim tehnologijama i izumima koje Intemet svakodnevno izbacuje na 
tržište. U nastavku su navedeni neki uobičajeni načini vođenja poslovanja koji se skoro 
više i ne obavljaju na dmgi, već isključivo na opisan način uz podršku elektronskog 
poslovanja. 

Elektronska faktura podrazumeva da menadžment preduzeća ima mogućnosti da 
svojim zaposlenima i poslovnim partnerima (kupcima) izdaje fakture u elektronskom 
obliku, bez potrebe štampanja istih jer se po međunarodnom pravu o elektronskoj 
trgovini svi dokumenti i elektronska komunikacija poslata sa službene adrese se 
smatraju punovažnim bez pečata i potpisa. Srbija još uvek nema adekvatan zakon o 
elektronskom poslovanju. Međutim, i tu postoji alternativa u obliku elektronskog 
potpisa koji se prilaže uz poslati dokument. Svako preduzeće ili privatno lice u Srbiji 
ima pravo da deponuje svoj elektronski potpis u Pošti Srbije ili u sudu. 

Elektronski radni nalog u slučaju velikih preduzeća, gde se svakodnevno između više 
službi/divizija, kao i na relaciji menadžment-ostali zaposleni, izdaje veliki broj radnih 
naloga i ostale vrste inteme komunikacije uz korišćenje adekvatnih programa za 
komunikaciju može da postigne veliku uštedu vremena, radnog materijala, kao i da 
poveća efektivnost inteme komunikacije. 

Efikasniji menadžment se postiže primenom servisa, pa dobija mnogo veću slobodu 
upravljanja i mnogo veću kontrolu izvršenja radnih naloga i zadataka. Menadžment 
stmktura preduzeća, počevši od top menadžmenta, pa do menadžera sektora, šefova 
radnih celina kao što su magacini, proizvodnja i prodaja, ima mogućnost praćenja 
izvršenja svih radnih zadataka, praćenja stanja u magacinu, o dnevnom i trenutnom 
učinku prodaje i slično, a da pri tome uopšte ne mora biti fizički prisutna u preduzeću. 

Računovodstveni programi služe za vođenja poslovnih knjiga i danas se sve to 
obavlja u elektronskom obliku uz pomoć različitih računovodstvenih i dmgih programa. 
Postoje i onjajn računovodstveni programi koji su dostupni uglavnom uz veoma male 
godišnje troškove uz odgovarajuće održavanje. 
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Elektronska evidencija zaliha u magacinima omogućava potpuno automatizovan 
proces nabavke i isporuke potrebnih artikala za određenu prodavnicu. To funkcioniše na 
taj način što, pri prodaji bilo kog artikla, automatski se u sistemu vodi količina 
određenih artikala u datoj prodavnici, te se sistem reprogramira tako da automatski šalje 
zahtev magacinu da se prodavnici pošalje određena količina artikala, čim broj artikala 
spadne do određene cifre, koja je unapred unesena u program. Time se isključuje ljudski 
faktor, komunikacija se ubrzava i čitavo poslovanje postaje efikasnije. 

Elektronsko vođenje i izveštavanje o završnim računima i generalnom uspehu 
poslovanja korišćenjem programa za vođenje završnih računa, kao i za periodične 
preseke o uspešnosti poslovanja, omogućava preduzeću da čitavo svoje poslovanje 
prikaže veoma transparentno za sve zainteresovane strane, a najpre omogućava 
sopstvenom menadžmentu da ima bolji uvid u poslovanje preduzeća. 

Elektronska prodavnica ( E-Shop ) omogućava da se tržište koje je nekada zavisilo od 
fizičkog prisustva i zauzimanja što bolje fizičke lokacije sada naglo prebaci na globalno 
tržište bez ikakvih ograničenja u poslovanju. Menadžment preduzeća treba da odluči da 
li će čitavu svoju ponudu postaviti na Internet i na koji će način to učiniti. Cinjenica je 
da postavljanje elektronske prodavnice ne zahteva kupovinu ili zakup poslovnog 
prostora, opreme, velikog broja radnika, potrošnog materijala i drugih radnih sredstava. 

Marketing, odnosno promocija roba i usluga na Intemetu može predstavljati osnovni 
prostor za oglašavanje u kojem preduzeće ima potpunu slobodu delovanja i izražavanja i 
mogućnost privlačenja novih klijenata i zadržavanja starih. 

2.3.4 Zakonodavni okvir elektronskog poslovanja 

Nedovoljna primena zajedničkih standarda eksplicitno znači suočavanje sa problemom 
nedostatka interoperabilnosti. Ukoliko se doda i nedovoljna koordinacija institucija i 
organizacija u primeni zajedničkih rešenja, problem nedostatka interoperabilnosti se 
uvećava. Da bi se problem umanjio, od vitalnog značaja je definisanje zakonskog okvira 
koji determiniše kontinuirano unapređenje procesa poslovanja i integracije na svim 
nivoima. 

U Srbiji na putu razvoja informacionog dmštva usvojena je potrebna zakonska 
regulativa koja u narednom periodu treba da se unapređuje. Širok kmg propisa koji 
pokrivaju oblast za sprovođenje poslova elektronskog poslovanja od značaja su i za 
nacionalni okvir interoperabilnosti, a odnose se na mere zaštite privatnosti, osiguranja 
bezbednosti, obezbeđenja potpisanih elektronskih dokumenata, čuvanja elektronskih 
zapisa, upravljanja elektronskim potpisom, upravljanja elektronskim poslovanjem, 
elektronskom pisamicom i elektronskom arhivom originalnih dokumenata. Uređivanje 
informacionog dmštva važan je deo usklađivanja pravnog okvira Srbije sa evropskim. 
Široki kmg propisa koji pokrivaju oblast za sprovođenje poslova za elektronsko 
poslovanje podjednako je značajan za nacionalni okvir interoperabilnosti. Stvaranje 
pravnog okvira za izgradnju informacionog dmštva, usklađenog sa razvojem tehnologije 
i međunarodnim standardima, započeto je sistemski nakon 2003. godine. Glavne 
smemice u tom procesu, osim strateških dokumenata Evropske unije, određene su u 
dokumentu Pakta za stabilnost Jugoistočne Evrope „eSEE Agenda+ za razvoj 
infonnacionog dmštva u Jugoistočnoj Evropi 2007-2012.” usvojenog 2007. godine 
[58], kao i u Vladinim dokumentima Strategija razvoja informacionog dmštva u 
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Republici Srbiji do 2020. godine [201], Strategija reforme državne uprave i nedavno 
usvojenoj Strategiji razvoja elektronske uprave u Republici Srbiji za period od 2009. do 
2013. godine. 

Zakoni Republike Srbije koji delinišu pravni okvir elektronskog poslovanja su: 

• Zakon o elektronskom poslovanju (Sl. Glasnik RS, br. 135/2004); 

• Odluka o elektronskom načinu obavljanja platnog prometa (Sl. Glasnik RS, br. 
57/2004); 

• Pravilnik o evidenciji sertifikacionih tela (Sl. Glasnik RS, br. 48/2005, 82/2005 i 
116/2005); 

• Pravilnik o bližim uslovima za izdavanje kvalifikovanih elektronskih sertifikata 
(Sl. Glasnik RS, br. 26/2008); 

• Pravilnik o registru sertifikacionih tela za izdavanje kvalifikovanih elektronskih 
sertifikata u Republici Srbiji (Sl. Glasnik RS, br. 26/2008); 

• Pravilnik o tehničko-tehnološkim postupcima za formiranje kvalifikovanog 
elektronskog potpisa i kriterijuma koje treba da ispune sredstva za formiranje 
kvalifikovanog elektronskog potpisa (Sl. Glasnik RS, br. 26/2008 i 13/2010); 

• Odlika o elektronskom potpisivanju dokumenta sa podacima koje banke 
dostavljaju Narodnoj banci Srbije (Sl. Glasnik RS, br. 28/2009 i 47/2009); 

• Zakon o elektronskoj trgovini (Sl. Glasnik RS, br. 41/2009); 

• Zakon o elektronskom dokumentu (Sl. Glasnik RS, br. 5 1/2009); 

• Strategija razvoja elektronske uprave u Republici Srbiji za period od 2009. do 
2013. godine (Sl. Glasnik RS, br. 83/2009 i 5/2010); 

• Pravilnik o izdavanju vremenskog žiga (Sl. Glasnik RS, br. 1 12/2009); 

• Uredba o elektronskom kancelarijskom poslovanju organa državne uprave (Sl. 
Glasnik RS, br. 40/2010); 

• Strategiia razvoia informacionog društva u Republici Srbiii do 2020. godine (Sl. 
Glasnik RS, br. 51/2010); 

• Strategija razvoja elektronskih komunikacija u Republici Srbiji od 2010. do 
2020. godine (Sl. Glasnik RS, br. 68/2010). 

Ostali srodni zakonski i podzakonski akti od značaja su: 

• Zakon o informacionoj bezbednosti; 

• Zakon o zaštiti podataka o ličnosti; 

• Zakon o tajnosti podataka; 

• Zakon o autorskim i srodnim pravima; 

• Zakon o slobodnom pristupu informacijama od javnog značaja; 

• Zakon o registraciji privrednih subjekata; 

• Zakonska regulativa na koju se oslanjaju informacioni sistemi za vođenje 
registara (centralni registar stanovništva, matični registri, registri prebivališta i 
boravišta, registri privrednih subjekata, registri nepokretnosti, registri korisnika 
zdravstvenog osiguranja i dr.); 

• Podzakonski akti Narodne banke Srbije u oblasti informacionih sistema u 
finansijskoj industriji u Srbiji. 

Zakoni o informacionom društvu doneti nakon 2003. godine u Republici Srbiji 
usklađeni su sa zakonodavstvom Evropske unije. Konkretno, to su: Zakon o registraciji 
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privrednih subjekata, Zakon o dostupnosti informacija od javnog značaja i Zakon o 
elektronskom potpisu, sa podzakonskim aktima. Donošenjem ovih zakona ustanovljeni 
su osnovi za primenu koncepta elektronskog poslovanja, kao što su uvođenje 
elektronskog potpisa i elektronskih scrtilikata, mogućnost dostavljanja zahteva stranaka 
elektronskim putem, pružanje usluga elektronskog poslovanja Intemetom, komunikacija 
stranaka i organa elektronskom poštom i slično. 

2.3.5 Okruženje za uvođenje elektronskog poslovanja u preduzeća 

Politički kontekst rezultat je usklađivanja različitih vizija i ciljeva organizacija. On 
predstavlja njihovu jasno izraženu volju i namem učestvovanja u postizanju zajedničkih 
ciljeva u procesu elektronskog poslovanja. Na temelju političkog konteksta mogu se 
prepoznati zajednički prioriteti, planirati zajedničke aktivnosti i delinisati ograničenja 
radi uspešnog uspostavljanja interoperabilnosti elektronskog poslovanja. Evropska unija 
svoju politiku u oblasti elektronskog poslovanja deklarisala je 1997. godine kao 
"evropsku inicijativu u oblasti elektronskog poslovanja". Na osnovu ove inicijative 
bliska su rešenja koje su zemlje članice pojedinačno donele u regulisanju digitalnog 
potpisa, sistema šifriranja i potvrde autentičnosti. U EU postoji najmanje 15 direktiva, 
predloga i prepomka koje pokušavaju da regulišu e-trgovinu. Skup predloga i prepomka 
je značajan iako izgleda da su te direktive donete deo po deo. EU je nastojala da u toj 
oblasti politički nametne zakonsku kontrolu i postoji težnja da svaka država inkorporira 
različite delove evropske zakonske regulative u svoje lokalne zakone. Neki od njih su 
Direktiva o e-potpisu, Direktiva o prodaji na daljinu i ugovaranju na daljinu, Direktiva o 
zaštiti podataka, Direktiva o e-trgovini i Direktiva o autorskom pravu. 

Pravni kontekst je suštinski za uspešan razvoj elektronskog poslovanja i zahteva 
ispunjenje i preduslova postojanja adekvatnih pravnih okvira. Ustavni osnov za 
donošenje Zakona o elektronskoj trgovini sadržan je u članu 97. tačka 6. Ustava 
Republike Srbije, kojima se utvrđuje da Republika Srbija uređuje i obezbeđuje, pored 
ostalog, jedinstveno tržište, pravni položaj privrednih subjekata, sistem obavljanja 
pojedinih privrednih i dmgih delatnosti. Stvaranje pravne regulative u oblasti 
elektronskog poslovanja započelo je donošenjem Zakona o elektronskom potpisu. Vlada 
Republike Srbije postupak daljeg razvoja, unapređenja i pravnog regulisanja 
elektronskog poslovanja nastavila je kroz donošenje Strategije razvoja informacionog 
dmštva u republici Srbiji i Strategije razvoja trgovine Republike Srbije.U Strategiji 
razvoja informacionog dmštva u republici Srbiji navodi se da elektronsko poslovanje u 
osnovi znači automatizaciju poslovnih procesa primenom informacionih i 
komunikacionih tehnologija i predstavlja efikasno sredstvo za obavljanje poslovnih 
aktivnosti na nacionalnom i međunarodnom nivou. Prema Akcionom planu e-Evropa 
2005, e-poslovanje obuhvata e-trgovinu (kupovinu i prodaju putem intemeta) i 
restmkturiranje poslovnih procesa sa ciljem realizacije najbolje upotrebe digitalnih 
tehnologija. Odgovomost je Vlade da prati razvoj novog zakonodavstva i uputstava u 
EU, i da na njima bazira praksu koju će primenjivati u domaćoj privredi. Informacije o 
aktuelnim evropskim zakonima i standardima važan su element poslovnog okmženja i 
njihova raspoloživost znatno će olakšati donošenje odluka na nivou kompanija i u 
različitim administrativnim organima. 

Tehničko - organizacioni aspekti upravljanja organizacijom, istorijski posmatrano, i 
obrada podataka su prošli kroz mčnu, mašinsku i elektronsku fazu. Smatra se da je 
mčna obrada stara koliko i poslovanje (mčno knjiženje, obračunavanje kamata itd.). 
Mašinska obrada je vezana za pojavu prve mehaničke mašine, koju je izmislio 
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matematičar Paskal, od tada je nastala čitava serija mašina za računanje i pisanje 
(računske mašine, polu automati, pisaće mašine, knjigovodstvene mašine). Pojavom 
prvog elektronskog računara počela je era računara, koja je do danas prošla kroz 
nekoliko faza - generacija računara. Tehnološke inovacije, pre svega novije generacije 
kompjuterske tehnologije, omogućavaju ubrzavanje poslovanja, čak i trenutnu 
povezanost raznih tržišta i mogućnost računanja sa svakim i najmanjim, vremenskim 
intervalom. U odnosu na tehničke aspekte savremenog poslovanja vrše se i 
organizaciona strukturiranja u okviru organizacija, tako da danas svaka organizacija ima 
i svoju informatičku podršku koja se sastoji od specijalista iz različitih oblasti 
informacionih tehnologija koji održavaju organizacionu interoperabilnost - poslovnu 
usklađenost između sistema (učesnika). Organizaciona interoperabilnost omogućava 
kvalitetno i održivo postizanje ciljeva definisanih političkim kontekstom unutar 
utvrđenih okvira pravne interoperabilnosti. Organizaciona interoperabilnost omogućava 
da sistemi efikasno povežu svoje procese radi pružanja zajedničke usluge nekom 
korisniku. U praksi, organizaciona interoperabilnost se uspostavlja kroz integraciju 
poslovnih procesa i sa njima povezanu razmenu informacija. Da bi različiti sistemi bili u 
mogućnosti da efikasno i delotvorno rade zajedno, oni treba da usklade svoje poslovne 
procese, a često i da definišu i uspostave nove poslovne procese. Usklađivanje 
poslovnih procesa podrazumeva njihovo dokumentovanje na opštedogovoreni način, 
tako da svi koji učestvuju u pružanju elektronskih usluga imaju globalni pogled na 
složene poslovne procese i razumeju svoju ulogu u njima, analogno definisanju odnosa 
među učesnicima u procesu interoperabilnosti. Organizaciona interoperabilnost 
obuhvata saradnju raznorodnih aplikacija u davanju konačnih elektronskih usluga. Ova 
dimenzija interoperabilnosti može se postići kroz posebne softverske aplikacije 
utemeljene na XML-\x (eXtensible Markup Language - XML), koje se nazivaju veb- 
servisima i koje su osnova servisno orijentisane, fleksibilne arhitekture (Service 
Oriented Architecture - SOA ). 

Semantički kontekst elektronskog poslovanja se ogleda u semantičkoj 
interoperabilnosti. To je sposobnost različitih sistema u procesu elektronskog 
poslovanja da na isti način tumače značenja infonnacija koje razmenjuju, a postiže se 
usklađivanjem semantičkih područja poslovanja između sistema. Semantička 
interoperabilnost odnosi se na uspostavljanje znanja koje poslovnim entitetima 
uključenim u proces elektronskog poslovanja obezbeđuje prevazilaženje semantičkih 
konflikata pri razmeni podataka. Semantički konflikti proizilaze iz razlika u korišćenim 
terminologijama za izražavanje poslovnih koncepata i konteksta, tj. domena u kojem se 
koncepti i podaci interpretiraju. Semantička aktiva ( Semantic Assets) obuhvata sve 
resurse potrebne za ostvarivanje semantičke interoperabilnosti, kao što su šifarnici, 
rečnici pojmova, XML šeme i slični popisi, specifikaciju njihovih međusobnih veza i 
pravila preslikavanja među njima. Semantika se povezuje sa razumevanjem i 
interpretacijom značenja podataka, dok se sintaksa povezuje sa razumevanjem i 
interpretacijom strukture podataka. 

Tehnički kontekst elektronskog poslovanja je ambijent koji se stvara da bi sistem 
mogao kontinuirano da posluje bez obzira na uslove koji vladaju. Iz tog razloga se 
formiraju primarni, backup (rezervni) i disaster sajt (u slučaju katastrofe). Svaki od 
sajtova treba da ima obezbeđeno neprekidno napajanje energijom koje se postiže 
uređajima za neprekidno napajanje (Uninterruptible Power Supply - UPS), sistemima 
agregata za permanentno obezbeđivanje izvora energije za sisteme za neprekidno 
napajanje, uređajima za održavanje odgovarajućih ambijentalnih uslova (na primer 
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temperature, vlažnosti vazduha), kao i odgovarajućim sistemima za detektovanja, 
alarmiranje i dojavu neusaglašenosti u sistemu i to po svakoj komponenti sistema 
posebno. Primarni sajt je planiran po kapacitetima za optimalan rad u normalnim 
uslovima. Posebnim tehnikama se obezbeđuje ažurna kopija podataka na backup i 
disaster sajtu da bi oni mogli da preuzmu funkciju u slučaju potrebe. Uobičajena je 
hardverska replikacija storage sistema u kombinaciji sa log shipping-om baze podataka. 
Primami sajt je od backup sajta udaljen nekoliko kilometara, dok se udaljenost disaster 
sajta treba meriti stotinama kilometara. Disaster sajt treba da zadovolji posebne uslove 
koji ga čine u slučaju katastrofe manje ranjivim, na primer da bude na drugoj tektonskoj 
ploči ukoliko se primarni sajt nalazi na trustnom području. Backup sajt je planiran za 
rad sa degradiranim performansama u slučaju da dođe do nemogućnosti funkcionisanja 
primamog sajta. Posebno se objavljuje rad na backup sajtu. Kapaciteti su planirani za 
ograničen rad i procesiranje ograničenog broja transakcija koje je neophodno obaviti za 
normalno funkcionisanje države. Nije predviđeno da se duži vremenski period 
procesiranje obavlja na backup sajtu, već samo do otklanjanja problema koji je nastao 
na primarnom sajtu. Pošto su svi uslovi rada normalni, dovođenje primamog sajta u 
fu nk cionalno stanje ne sme da traje dugo. Disaster sajt treba da ima performanse bliske 
primamom sajtu jer se predviđa rad na disaster sajtu u uslovima velikih poremećaja, na 
primer zemljotresa, terorističkog napada na primami sajt i slično, gde je šteta na 
primamom sajtu velika i nije moguće dovesti u fu nk cionalno stanje u kratkom 
vremenskom periodu. 

Komunikaciona infrastmktura treba da obezbedi tehničku interoperabilnost, siguran i 
zaštićen prenos informacija (potpisivanje sadržaja, kriptovanje sadržaja, kriptovanje 
komunikacije). Vrši se posebno segmentiranje mreže na svim nivoima u posebne 
zaštićene zone za svaki operativni segment, posebno se isturaju komunikacioni čvorovi 
prema centrima za komunikaciju koji su vidljivi ostalim učesnicima, komunikacioni 
centri su u posebno zatvorenim mrežama u kojima su poznati učesnici koji se vladaju 
prema određenim pravilima. Prave se planovi rada mreže u odnosu na normalan rad, rad 
u otežanim uslovima sa backup sajtom i rad u katastrofalnim uslovima na disaster sajtu. 

Prilikom projektovanja hardverskih komponenata vodi se računa o tome da kod svake 
hardverske komponente ne postoji single point of failure. Svaka hardverska komponenta 
treba da bude multiplicirana da u slučaju otkaza jedne komponente sistema nastavi 
normalno da radi, a sistem hardverskih komponenata da bude tako projektovan da je 
moguće sistem skalirati u slučaju potrebe za povećanjem kapaciteta. Hardverska 
infrastruktura se sastoji od storage sistema za sigurno pohranjivanje velikih količina 
podataka, odgovarajuće komunikacione infrastrukture za obezbeđivanje brze 
komunikacije između hardverskih komponenti sistema na sajtu (uglavnom fiber channel 
infrastruktura), serverske infrastrukture, infrastrukture za pravljenje rezervne kopije 
podataka i trajno skladištenje podataka, kao i hardverske infrastrukture za udaljenu 
replikaciju podataka. Operativni sistemi i sistemski softver determinisani su 
aplikativnim rešenjem sistema. 

Organizacione promene nastale uvođenjem elektronskog poslovanja ogledaju se u 
mogućnostima koje elektronsko poslovanje donosi. One se pre svega ogledaju u 
izmenjenom načinu obavljanja poslovnih transakcija, radnom vremenu, prostornoj 
neograničenosti, brzini obavljanja poslovnih transakcija, umanjenoj ceni poslovne 
transakcije, ali i u potrebi za povećanjem sigumosti zbog izmenjenog načina obavljanja 
transakcija, izmeni poslovnih procesa, kadrovima koji su potrebni da bi se izvršila 
poslovna transakcija. Po pitanju radnog vremena, elektronsko poslovanje omogućuje 
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bez dodatnih ulaganja u resurse neograničeno radno vreme (24 sata dnevno, sedam dana 
u nedelji, 365 dana godišnje). U tradicionalnom poslovanju za obavljanje poslovnih 
transakcija bilo je potrebno angažovati veliki broj zaposlenih u tri smene u čitavoj 
poslovnoj mreži, tako da su troškovi poslovanja van tradicionalnog radnog vremena bili 
izuzetno veliki. Struktura organizacionih jedinica je izmenjena u smislu da uvođenjem 
elektronskog poslovanja moraju da postoje specijalizovani sektori za tekuće održavanje, 
za sistemsku podršku i za aplikativnu podršku, koji se sastoje od infonnatičara 
specijalizovanih za sve aspekte podrške elektronskom poslovanju. I tehnolozi posla, 
kadrovi koji obavljaju poslovne procese, imaju posebne zadatke u odnosu na 
tradicionalno poslovanje i moraju da poseduju adekvatna znanja za korišćenje 
infonnacionih tehnologija. Pored vremenske neograničenosti, prostoma neograničenost 
donosi nove mogućnosti organizacionih promena uvođenjem elektronskog poslovanja. 
Radnik više nije vezan za mesto, pa čak ni za zemlju gde postoji organizaciona jedinica 
kojoj pripada, već se dodeljivanjem odgovarajućih privilegija u sistemu može omogućiti 
udaljen pristup i dati mogućnost obavljanja poslovnih transakcija koje su mu dodeljene. 
U klasičnom poslovanju bilo je potrebno potrošiti vreme za dolazak i odlazak u 
poslovnu jedinicu radi obavljanja poslovne transakcije uz utrošak dodatnog vremena za 
obavljanje same poslovne transakcije. Elektronsko poslovanje omogućava 
obezbeđivanje potrebnih informacija za obavljanje poslovne transakcije, izvršenje 
poslovne transakcije i distribuciju informacija o obavljenoj poslovnoj transakciji bez 
utroška vremena za ličnu idcntifikaciju poslovnog subjekta, odnosno odlaska i dolaska 
poslovnog subjekta u jedinicu i kasniju distribuciju infonnacije o obavljenoj transakciji. 
Ukoliko su informacije spremne, u elektronskom poslovanju akvizicija informacija 
potrebnih za poslovnu transakciju, obavljanje transakcije i distribucija informacija o 
poslovnoj transakciji gotovo je trenutna ukoliko su ispunjeni svi uslovi za obavljanje 
transakcija. Vremenska neograničenost, prostorna neograničenost i brzina obavljanja 
poslovne transakcije čine da je cena poslovne transakcije u elektronskom poslovanju 
niska. Pošto se poslovne transakcije moraju obavljati u bezbednom okruženju i na 
siguran način, moraju postojati odgovarajući mehanizmi koji organizaciono obezbeđuju 
ta dva aspekta, a koji uvećavaju troškove poslovne transakcije. 

2.3.6 Elektronsko poslovanje platnih sistema u svetu i kod nas 

Platni sistem je jedan od osnovnih podsistema (inansijskog sistema. Stručna javnost 
tokom poslednje dve decenije [198] posvećena je proučavanju, razvoju i implementaciji 
standarda vezanih za ovu oblast. Ključni razlog tolikog interesovanja može se odslikati 
kroz sledeće: pouzdan i efikasan platni sistem jeste jedna od osnovnih pretpostavki 
efikasnog funkcionisanja celokupnog finansijskog sistema države. Pored stručne 
javnosti, platnim sistemima poseban značaj pridaju i međunarodne finansijske 
institucije, organizujući internacionalne komitete koji se bave navedenom oblašću i 
proklamovanjem odgovarajućih standarda, preporuka i smernica. Institucija koja je 
utemeljivač osnovnih standarda vezanih za ovu oblast je Bank For International 
Settlemens - BIS, u Bazelu u okviru koje funkcioniše Commitee for Pavment and 
Settlement Svstems. Platni promet se organizuje i razvija u skladu sa ekonomsko- 
finansijskim razvojem zemlje i uspostavljenim odnosima poverenja između centralne 
banke i poslovnih banaka. Razvoj platnog prometa prati stalno usavršavanje 
organizacije, načina oblika i instrumenata plaćanja. U svetu nema jedinstvenog i 
idealnog načina organizovanja platnih sistema. Savremeno organizovan platni promet 
pruža učesnicima u plaćanju mogućnost korišćenja savremenih i prikladno kreiranih 
instrumenata plaćanja, kao i mogućnost izbora i korišćenja oblika i načina plaćanja. Da 
bi platni promet bio tačan, efikasan i ekonomičan, mora postojati uzajamna usklađenost 
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između organizacije procesa plaćanja, instrumenata, oblika i načina plaćanja. 
Savremeno organizovan platni promet zasnovan je na korišćenju informaciono- 
komunikacione tehnologije. Platni promet se odvija razmenom elektronskih poruka kroz 
informacione sisteme učesnika. Elektronskom porukom smatra se infonnacija koje je 
elektronski generisana, poslata, proverena, primljena i sačuvana. Struktura poruka 
utvrđena je od strane zakonodavnog organa, obično centralne banke. Validnom 
elektronskom porukom smatra se svaka elektronska poruka propisanog formata, koja je 
overena elektronskim potpisom i primljena u skladu sa propisanim pravilima. U 
razvijenim tržišnim ekonomijama danas egzistiraju različiti modeli sistema obračuna 
platnog prometa. Kada su u pitanju transakcije velikih vrednosti, različitost ovih modela 
sastoji se u izboru operatera sistema, što je uglavnom centralna banka, u izboru vrste 
obračuna, odnosno bruto i neto obračuna, i mogućnosti korišćenja intradnevnog 
kreditiranja i izboru funkcije operacione kontrole pri upravljanju veličinom 
intradnevnog kredita. 

SEPA ( Single Euro Pavments Area) trenutno je najveći zajednički projekat evropske 
bankarske industrije. Iniciran je neusaglašenošću da građani ne mogu da koriste iste 
naloge za plaćanja, naloge za naplatu i platne kartice na isti način na čitavoj teritoriji 
Evropske unije. Na planu integracije i harmonizacije velikih plaćanja [179] zajedno sa 
Evropskom monetamom unijom 1999. godine pušten je sistem Target. To je zajedno sa 
Fedwire sistemom najveći RTGS (Real Time Gross Settlement) sistem u svetu. Target 
je tehnički distribuiran, sastoji se od tehnički decentralizovanih platformi. Target 2 
predstavlja nadogradnju sistema Target baziran je na jedinstvenoj, zajedničkoj platformi 
i podrazumeva standardizaciju tehnologije, efikasnije procesiranje i efikasnije 
upravljanje likvidnošću, a po pitanju platforme, za razliku od Targeta prestavlja 
tehnički centralizovan sistem. Na planu malih plaćanja Europen Payment Council čini 
napore na polju transfera zaduženja, transfera odobrenja i platnih kartica. Suočava se sa 
problemima odsustva interoperabilnosti pošto je zona izdeljana na različite nacionalne 
platne sisteme, od kojih je svaki zadržao specifična rešenja koja su okrenuta prema 
običajima i potrebama sopstvenih korisnika i zahtevima domaćeg zakonodavstva. 
Razlike među tim sistemima su u pogledu tehnologije realizacije, postupaka, standarda, 
vrste usluga, bankarskih tarifa i sadržaja koji se koriste u režimu međubankarskih 
obračuna i plaćanja. 28.01.2012. godine pušten je SEPA credit transfer instrument 
plaćanja, što znači da je 27 zemalja članica, Island, Lihtenštajn, Norveška i Svajcarska 
dobilo jedinstveni instrument za obavljanje bankarskih poslova. Očekuje se da će do 
2015. godine u SEPA oblasti važiti jedinstveni formulari i pravila i za sve ostale 
instrumente plaćanja i da će sve novčane transakcije u evrima moći da se odvijaju preko 
bilo kog tekućeg računa u Evropi pod istim uslovima. 

2.4 Globalni standardi elektronskog poslovanja 

Standard kao termin u disertaciji koristi se u širem smislu i pokriva dokumente, koji 
obezbeđuju pravila, smernice i karakteristike za aktivnosti i njihove rezultate, sa ciljem 
postizanja optimalnog stepena reda u datom kontekstu [83]. Primena standarda olakšava 
postizanje interoperabilnosti sistema elektronskog poslovanja. Međutim, rad na razvoju 
i sprovođenje standarda ne znači da će interoperabilnost, i pored primene standarda, biti 
automatski postignuta. Standardi u oblasti interoperabilnosti kreiraju se da bi osigurali 
konzistentnost između uređaja, platformi i sistema. Oni promovišu interoperabilnost 
sistema, tako što obezbeđuju da se proizvodi, kreirani korišćenjem različitih tehnologija, 
mogu zajedno koristiti [75]. 
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Standardizacija elektronskog poslovanja je globalan proces i odvija se permanentno 
u interesom povezanim organizacijama za razvoj standarda. Standardizacija se odvija na 
svim nivoima i vrlo često se za istu grupu standarda formiraju različite organizacije 
pošto je interes povezanih struktura koje iniciraju razvoj standarda da imaju standard 
pod svojom kontrolom. Standardizacija elektronskog poslovanja odvija se, pre svega, 
prema oblastima poslovanja: (inansije, lanci snabdevanja, javna uprava, meteorologija, 
javni saobraćaj, hotelijerstvo i mnogi drugi. Standardizacija elektronskog poslovanja 
prema oblastima jeste, u stvari, standardizacija instrumenata elektronskog poslovanja 
kroz standardizaciju standardizacija podataka, odnosno poruka i poslovnih procesa, to 
jest načina upotrebe poruka. Komponente od kojih se sastoje složeni poslovni objekti 
uglavnom nisu standardizovane i na tom polju se takođe vrši standardizacija od strane 
organizacije UN/CEFACT koja standardizuje osnovne komponente (Core Components ). 
Na taj način se vrši standardizacija objekata poslovanja (standardizacija metapodataka) i 
standardizacija podataka. U svakoj oblasti poslovanja možemo za vrlo kratko vreme 
pronaći nekoliko standarda koji se u isto vreme standardizuju, koji se preklapaju ili koji 
su naslednici drugih, postojećih standarda, koji su još uvek u upotrebi. Ovi globalni 
standardi imaju svoju očiglednu prednost zbog interoperabilnosti na nivou procesne i 
semantičke interoperabilnosti ali u većini slučajeva nisu pogodni sa stanovišta 
isplativosti primene zbog toga što je promovisanje novih standarda veoma agresivno i 
često, pa, iako su novi standardi napredniji, veoma česta izmena sistema elektronskog 
poslovanja nosi sa sobom neprihvatljive troškove poslovanja. Standardizacija razmene 
podataka danas ide do tog nivoa da se nad standardnim protokolima implementiraju 
sistemi za logičku razmenu podataka koji ne zavise od konkretnog protokola i mogu se 
primeniti nad raznim postojećim protokolima ili nekim budućim. Sintaksna 
interoperabilnost postiže se upotrebom XML standarda u standardizaciji svake oblasti 
poslovanja i uz tehničku interoperabilnost savremeni standardi su po ovom pitanju 
usaglašeni. Globalni standardi elektronskog poslovanja prate sva tri nivoa 
interoperabilnosti i najveća je neusaglašenost na nivou semantičke interoperabilnosti jer 
poslovni sistemi koji iniciraju izradu standarda žele da imaju presudan uticaj i kontrolu 
nad ovim segmentom kao tehnološkom inovacijom, a samim tim nad čitavim 
predmetnim domenom. 

2.4.1 Standardizacija informacionih tehnologija 

Standardizacija u oblasti informacionih tehnologija ogleda se pre svega u uvođenju 
standarda u izgradnji infrastrukture elektronskog poslovanja, odnosno data centara, 
sprovođenju tehnologije virtualizacije i primeni cloud computing tehnologije. Navedene 
tri kategorije informacionih tehnologija u poslednje vreme zauzimaju značajno mesto u 
izgradnji sistema elektronskog poslovanja i postaju de facto standard za implementaciju. 

Standardizacija u oblasti data centara [169] obezbeđuje da se pružanje IT 
operativnih i poslovnih servisa vrši u skladu sa najvišim industrijskim standardima 
zaštite. Tier klasifikacija data centara odnosi se na opis infrastrukture data centara po 
nivoima, sa ciljem održavanja određenog nivoa operativnosti celokupnog data centra. 
Karakteristike pojedinih sistema ili podsistema data centra samo su deo ukupne slike 
Tier standardizacije data centra. Za svaki od podsistema definiše se redundantnost i 
vreme ispravnog rada kako bi se ispunili specifični Tier zahtevi raspoloživosti. Ocena 
data centra daje se na osnovu ocene najslabijeg podsistema koji utiče na raspoloživost 
celokupnog data centra. Data centri imaju višestruke, fizički izolovane podsisteme, koji 
omogućavaju potpunu redundantnost na nivou napajanja i sistema hlađenja. TIA 942 
standard sadrži preporuke koje se odnose na dizajn prostora namenjenog za data centar, 
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strukturno kabliranje, usklađivanje sa Tier standardima i okruženje. Objekti data centara 
mogu da imaju i više hiljada kvadratnih metara korisne površine, sa prostorom za utovar 
i istovar opreme, teretnim liftovima i namenskim parkingom za vozilo za dolivanje 
goriva. Klasifikuju se kao objekti kategorije I, za VIII seizmičku zonu po MCS 
(. Mercalli-Cancani-Sieberg ) skali. Objekat treba da obezbeđuje redundansu od najmanje 
za sledeće sisteme: električne, mehaničke i infrastrukturu telekomunikacionog 
povezivanja. Data centar treba da je direktno povezan na gradsku elektro-energetsku 
mrežu preko dve različite trafo-stanice, pomoću dve nezavisne grane za napajanje. 
Trase podzemnih vodova treba da su potpuno fizički razdvojene. Sistemi napajanja 
električnom energijom treba da su projektovani su tako da je moguće održavanje jedne 
od grana napajanja bez uticaja na funkcionalnost sistema u celini. Dizel generatori sa 
podzemnim sezonskim rezervoarima treba da obezbeđuju kontinuirano napajanje data 
centra u trajanju od 72 časa, pri punom kapacitetu, a bez dolivanja goriva. Generatori se 
automatski startuju pri prekidu osnovnog elektro-energetskog napajanja. Kapacitet 
generatora pokriva sva kritična opterećenja celokupnog data centra. UPS sistem treba da 
se sastoji iz dva nezavisna UPS podsistema sa autonomijom rada od više desetina 
minuta pri punom projektovanom opterećenju data centra. Centralni sistem za nadzor i 
upravljanje treba da omogućava stalno praćenje temperature i vlažnosti vazduha za 
svaku od soba s opremom. Sistem za detekciju i rano otkrivanje požara u data centru 
obično koristi laserske detektore za rano otkrivanje dima koji obezbeđuju rano 
upozorenje o promenama u bilo kom delu data centra. Kontrola fizičkog pristupa 
opremi korisnika sprovodi se preko odgovarajućih bezbednosno-sigurnosnih sistema, 
pri čemu je obezbeđena višestruka mehaničko-elektronska kontrola ulaska u objekat i 
sobe sa opremom. Objekat treba da je obezbeđen sigurnosnom ogradom, uz potpuno 
kontrolisani pristup ulazu koji je opremljen dvadesetčetvoročasovnim sistemom video- 
nadzora i uz stalno prisustvo fizičkog obezbeđenja. Kontrola pristupa prostorijama u 
data centru treba da je sprovedena u skladu sa unapred dodeljenim korisničkim pravima 
pristupa i bezbednosnim procedurama, koje podrazumevaju i autentifikaciju preko PIN 
kodova i čitača ID kartica, koji su instalirani na svim vratima u data centru. 

Virtualizacija je tehnologija čijim korišćenjem može da se izvrši smanjenje troškova 
po pitanju hardvera, potrošnje električne energije i prostora predviđenog za smeštanje 
prateće IT opreme. Korišćenjem ove tehnologije vrši se dinamično povećanje 
iskorišćenja IT resursa, povećava se njihova fleksibilnost i bezbednost, uz konsolidaciju 
računarske opreme. Virtualizacija se preporučuje kao najbolje rešenje za povećanje 
pouzdanosti i otpornosti na otkaze IT resursa, kao i kod projektovanja rešenja za 
oporavak od svih vidova katastrofa. Sama tehnologija doprinosi i očuvanju životne 
okoline, te se svrstava u porodicu green tehnologija. Virtualizacija obuhvata serversku 
infrastrukturu, radne stanice i aplikacije. Ubrzani razvoj Intemeta, hardverskih 
komponenata i sistemskog softvera rezultovao je ekspanzijom broja servera, servisa i 
aplikacija u data centrima. U cilju efikasnog iskorišćenja IT resursa i ozbiljnog 
smanjenja inicijalnog i operativnog ulaganja u IT došlo je do razvoja savremenog 
rešenja koje danas nazivamo virtualizacijom. Virtualizacija servera predstavlja 
tehnologiju koja omogućava da se na jedan fizički server „smesti” više virtualnih 
servera, u cilju optimizacije sistema, povećanja bezbednosti, lakšeg održavanja i 
investiranja u hardver, prostor i električnu energiju. Virtualizacija desktop infrastrukture 
podrazumeva tehnologiju pomoću koje se korisniku uz pomoć kompjuterske mreže 
ispomčuje centralizovana virtuelna mašina iz računarskog data centra (radna stanica). 
Tehnologija zahteva servere na kojima se smeštaju virtuelne radne stanice, kao i fizički 
tanki klijent, ili računar za komunikaciju sa serverima. Virtualizacija radne površine 
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zasniva se na dinamičkoj isporuci virtuelnog Microsoft Windows operativnog sistema - 
radne površine u obliku servisa, bez obzira na lokaciju istog, uz neophodan uslov da 
postoji mrežna komunikacija sa serverskom infrastrukturom. Virtualizovane radne 
stanice se po funkcionalnosti i izgledu ne razlikuju od klasičnih radnih stanica na 
kojima je lokalno instaliran operativni sistem. Ovakav koncept donosi niz ušteda i 
obezbeđuje znatno jednostavnije i jeftinije održavanje operativnih sistema na radnim 
stanicama. Ukupna cena primenom virtualizacije radne površine može biti smanjena i 
do 40%. U cilju obezbeđivanja kontinuiranog rada informacionih sistema, kao i zaštite 
servisa i aplikacija od katastrofe, potrebno je obezbediti visoko dostupne servise koji će 
geografski biti smešteni na drugu lokaciju. Danas je uz pomoć savremenih tehnologija 
moguće implementirati i integrisati virtuelnu IT infrastrukturu u poslovno okruženje na 
jednostavniji, brži i ekonomski isplativiji način. 

Cloud Computing ili računarski oblak predstavlja skup podataka i usluga koje 
koegzistiraju u deljenom skalabilnom skupu resursa zasnovanom na tehnologiji 
virtualizacije i / ili skaliranim aplikativnim okruženjima. To je model koji omogućava 
jednostavan mrežni pristup, na zahtev korisnika, deljenom skupu resursa (na primer 
mrežni resursi, serveri, prostor na hard diskovima, aplikacije i servisi), koji mogu da 
budu brzo dostupni za upotrebu ili ugašeni, a sa minimalnim intervencijama, ili 
akcijama od strane pružaoca usluga. 

Ovakav model sastoji se od sledećih karakteristika: 

• Samostalno korišćenje na zahtev (Korisnik može da koristi resurse kada on to 
želi, sa bilo kojeg mesta i u bilo koje vreme putem globalne mreže. Ovi resursi 
podrazumevaju serversko vreme ili mrežni prostor, fizički prostor na skladišnim 
uređajima, kojima se pristupa bez potrebe za ljudskom intervencijom bilo kod 
klijenta, ili kod servis provajdera usluga). 

• Širok spektar mogućnosti mrežnog pristupa (Mogućnosti sistema dostupne su 
klijentima putem mreže i može im se pristupiti sa različitih uređaja, kao što su 
desktop računari, mobilni telefoni, smartphone i tablet uređaji). 

• Alokacija resursa (Računarski resursi provajdera su grupisani kako bi opslužili 
veliki broj istovremenih korisnika). Mehanizam raspodele procesorske snage, ili 
količine memorije, fu nk cioniše tako što sistem dinamički vrši raspodelu ovih 
parametara prema zahtevima korisnika. Sami korisnici nemaju kontrolu nad 
fizičkim parametrima, odnosno nad lokacijom resursa, ali na nekim višim 
nivoima podešavanja svog sistema u okviru Cloud rešenja mogu da izaberu gde 
će njihovi podaci biti smešteni i procesirani (na primer geografski položaj data 
centara). 

• Elastičnost i fleksibilnost sistema (Mogućnosti Cloud rešenja mogu u veoma 
kratkom vremenskom periodu da budu dostupne korisniku sistema, ukoliko on 
ima potrebu za tim. Pretpostavimo da se naš sajt nalazi u oblaku i da nam je 
promet u smislu broja posetilaca sličan svakoga dana. Zatim, pretpostavimo da 
jednog dana, iz nekog razloga, posećenost veb-prezentacije skoči za 100%. 
Ukoliko je sajt hostovan na našem, privatnom serveru, postoji velika mogućnost 
da se on jednostavno ,,sruši“ i prestane sa radom, zbog softverskih i hardverskih 
ograničenja. U takvim slučajevima, Cloud dinamički dodeljuje potrebne resurse 
kako bi obezbedio nesmetano funkcionisanje, a kada promet ponovo opadne, 
resursi se automatski vraćaju u prvobitno stanje. Korisnik može da kupuje 
dodatne resurse i mogućnosti u bilo kojim količinama i bilo kada). 
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• Merljiva usluga - plaćanje po utrošku ( Cloud sistemi automatski kontrolišu i 
optimizuju neophodne resurse u zavisnosti od potreba korisnika i tipa usluge 
koja se traži (prostor na disku, procesorska snaga, količina RAM-a i slično). Sve 
ove usluge su merljive i njihovo korišćenje je transparentno, kako za provajdera, 
tako i za klijente. To je veoma važno jer finansijski momenat igra veliku ulogu 
kad je u pitanju ova nova tehnologija, naročito za velike, enterprise sisteme i 
kompanije). 

Postoje tri servisna modela: 

• Sofhvare as a Service - SaaS (SaaS omogućava klijentima da koriste usluge 
podešavanja i korišćenja aplikacija koje se nalaze na infrastrukturi pružaoca 
usluga. To znači da provajder obezbeđuje potreban hardver (serveri, memorije, 
procesori i sl.), kao i aplikaciju koja je klijentu potrebna. Njoj može da se 
pristupa preko različitih uređaja i interfejsa, kao što je veb Browser (Internet 
Explorer, Mozilla Firefox, Chrome, Safari, Opera...). Primer ovog modela je 
webmail, kao što su Yahoo ili G-Mail. Kod ovog modela, korisnici nemaju 
kontrolu nad konfiguracijom hardvera i softvera koji koriste). 

• Platform as a Service - PaaS (Cloud platforma kao usluga predstavlja model u 
kome korisnici koriste aplikacije koje su kupili ili sami razvili, a u Cloudu 
koriste platformu koja će njihovu aplikaciju podržati. U ovom slučaju, klijenti 
nemaju kontrolu nad hardverom provajdera, već samo nad svojim softverom koji 
se nalazi u Cloudu). 

• Infrastructure as a Service - IaaS (Cloud infrastruktura kao usluga jeste model u 
kome klijenti dobijaju na raspolaganje hardverske resurse i tehnologiju u vidu 
procesorske snage, prostora na disku, operativnih sistema i slično. Ne postoji 
mogućnost kontrole samog hardvera, ali moguće je upravljati operativnim 
sistemima, prostorom na disku, aplikacijama, i u posebnim slučajevima odabrati 
neke dodatne opcije provajdera, kao na primer Firewall, monitoring aplikacija i 
hardverskih resursa). 

Postoje četiri modela računarskog oblaka: 

• Privatni Cloud (Privatna Cloud infrastruktura je u vlasništvu organizacije i 
njome upravlja sama organizacija (kompanija) ili treća lica koja to rade za njih 
(outsourcing). Ovakav model može da bude fizički smešten u okviru prostorija 
organizacije ili dislociran na neko drugo mesto. IT infrastruktura se fizički 
smešta u posebno tehnički definisane prostore koji se nazivaju data centri). 

• Zajednički Cloud (Kod ovog modela, infrastruktura je deljena između nekoliko 
organizacija i pruža podršku grupi organizacija (ili kompanija) koje dele iste 
interese, kao što su misija i vizija, sigurnosna politika i slično. Kao i u 
prethodnom slučaju, njime može biti upravljano od strane interno zaposlenog 
osoblja ili kroz outsourcing model usluga). 

• Javni Cloud (U ovom slučaju sistem je u posedu kompanije koja se bavi 
prodajom Cloud usluga i dostupan je svim pojedincima i poslovnim subjektima. 
Ovde se podrazumevaju svi servisi i usluge koji su putem globalne mreže javno 
dostupni krajnjem korisniku bez obzira na njihovu lokaciju. Dobar primer su 
socijalne mreže Facebook, Twitter). 

• Hibridni Cloud (Model koji je sastavljen od dva ili više prethodno navedenih 
Private, СоттипИу, Public u kome svaki od njih ostaje nezavisan, ali su 
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međusobno povezani prateći clcfinisane standarde i procedure kako bi se 
obezbedila mobilnost podataka između njih [88]. Tako, na primer, velika 
kompanija može svoj sistem da drži većinom u privatnom oblaku, dok neke 
poslovne funkcije može da prebaci u javni oblak, recimo slanje velikog broja e- 
mail-ova, kako bi rasporedila opterećenje sistema prema svojim potrebama). 

Prednosti virtualizacije su sledeće: uštede u prostoru i energiji, uštede u novcu i 
vremenu, lakše proširivanje sistema, bolje iskorišćenje sistema, dugotrajna i pouzdana 
platforma, lakše i jeftinije upravljanje, jednostavnije održavanje, fleksibilnost IT servisa 
koji se nalaze na virtuelnoj infrastrukturi, visoka dostupnost, jednostavan i brz oporavak 
aplikacija, jednostavna migracija i migriranje podataka, automatizovana procedura 
oporavka servisa i aplikacija. 

2.4.2 Standardizacija elektronskog poslovanja 

Organizacija kao i tehnologija moraju se definisati, a definišu se u odnosu standarde 
koji su usvojeni od strane za to ovlašćenih nadležnih institucija. U elektronskom 
poslovanju vrši se: 

Standardizovanje organizacionih procedura i dokumentovanje njihovog izvršenja 

je regulisano u Srbiji JUS ISO standardom 9001 tj. Standardima za upravljanje 
kvalitetom. Mogu biti aktuelni i drugi relevantni standardi usko povezani sa 
predmetnom oblasti poslovanja. 

Standardizovanje profesionalnih procedura rada i dokumentovanje njihovog 
izvršenja doprinosi jasnom definisanju skupa podataka koji treba prikupljati i zaštititi. 

Tehnološki standardi vezani za informacione tehnologije odnose se, na primer na 
obavezu posedovanja licenciranih antivirusnih programa, korišćenje određenih 
protokola prenosa, sprovođenje posebnih mera zaštite i slično. 

Standardi iz oblasti predmetne informatike predstavljaju standarde koji regulišu 
uvođenje informacionih tehnologija u predmetnu oblast elektronskog poslovanja i 
odnose se na arhitekturu informacionog sistema, minimalne setove podataka, sadržaj 
standardnih XML poruka za razmenu podataka u predmetnom poslovnom sistemu, 
preporučene standarde za sigumost, privatnost i poverljivost i preporuke za legistativu. 

Standardizacija u oblasti upravljanja sigurnošću informacija postiže se uvođenjem 
familije ISO/IEC 17799. standarda koju čine: osnove i rečnik pojmova, zahtevi, kodeks 
postupaka (dobra praksa) za upravljanje sigurnosti informacija, uputstvo za 
implementaciju, merenja u menadžmentu sigurnosti informacija, menadžment rizika 
sigumosti infonnacija . Standard se bazira na sledećim kategorijama koje pokrivaju 
aspekte sigurnosti informacija: sigumosna politika, organizacija za sigurnost 
informacija, upravljanje resursima, sigurnost ljudskih resursa, fizička sigurnost, 
upravljanje komunikacijama i operacijama, kontrola pristupa, nabavka, razvoj i 
održavanje informacionih sistema, upravljanje sigumosnim incidentima, upravljanje 
kontinuitetom poslovnih procesa, usklađivanje sa zakonskim i dmgim propisima. Svaka 
od navedenih sigumosnih kategorija definiše sigumosne ciljeve kao i kontrole koje je 
potrebno sprovesti da bi se ispunili ti ciljevi. Važno je napomenuti da se kontrole 
definišu kao: način upravljanja rizicima, što podrazumeva politike, procedure, uputstva, 
organizacione stmkture koje mogu da budu administrativne, tehničke, upravljačke ili 
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pravne. Paralelno sa ovim standardom razvijan je standard (ISO/IEC 27001) koji 
dcfi nišc zahteve koje menadžment sistem za sigurnost informacija mora da zadovolji i 
po kome se sprovodi i sertifikacija ako se to zahteva. Ovi zahtevi baziraju se na 
ciljevima i kontrolama (dobroj poslovnoj praksi) koje su definisane u standardu 
ISO/IEC 17799. Ceo koncept sigurnosti informacija koji je definisan u standardima 
ISO/IEC 27001 i ISO/IEC 17799 bazira se na konceptu upravljanja rizicima. Ocena 
rizika je definisana kao ocena pretnji informacijama (pretnje koje dovode do povrede 
poverljivosti, integriteta i raspoloživosti infonnacija) njihovog uticaja na infonnacije i 
na ranjivost (slabost) informacija i informacionih sistema, kao i verovatnoće njihove 
pojave. 

2.4.3 Standardizacija elektronskog poslovanja platnih sistema 

Standardizacija elektronskog poslovanja platnih sistema odvija se u tri osnovna pravca: 

1. Harmonizacija zakonske regulative sa inovacijama na finansijskom tržištu, 
koja se uglavnom ogleda na najnovijim inicijativama Evropske unije u skladu sa 
IS020022 standardom [98] u čijoj specifikaciji učestvuju sve vodeće finansijske 
institucije; 

2. Usklađivanje standarda na nivou semantičke interoperabilnosti: UNIFI 
(IS020022) poruke u sebi sadrže elemente svih relevantnih standarda dobijenih 
reverznim inženjeringom i tako igraju ključnu ulogu u konvergenciji ostalih 
standarda ka jedinstvenom, opšteprihvatljivom standardu. Na slici 2. prikazana 
je uloga UNIFI osnovnog platnog modela. Sa slike je vidljivo da univerzalni 
standard za finansijske poruke ima zadatak da bude kopča između prikazanih 
standarda, odnosno, da prevodi sintaksu jednog standarda u drugi, te tako učini 
poruke jednog standarda prepoznatljivim od strane drugog standarda. Iterativnim 
izmenama u ostalim standardima vremenom bi svi standardi konvergirali ka 
jedinstvenom UNIFI standardu, a do pojave jedinstvenog svetskog standarda svi 
finansijski sistemi implementirani na osnovama različitih standarda mogli bi da 
sadejstvuju. 

3. Pooštravanje standarda za upravljanje informacionim sistemima 

finansijskih institucija u skladu sa standardima IS02700x. 


Radovi u smeru sadejstva i konvergencije 




Reverznim inženjeringom dobijaju se kanonički 
UNIFI model poruka i „tabele konvergencije" 


Slika 2. Radovi u smeru sadejstva i konvergencije u standardizaciji XML poruka 
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Najvažnija inicijativa u standardizaciji elektronskog poslovanja platnih sistema koja će 
biti preovlađujuća i u budućnosti jeste IS020022 [99], [113]. ISO je mreža nacionalnih 
institucija za standardizaciju. Intemacionalni standard ISO 20022 je inicijalno priređen 
od strane Tehničkog komiteta ISO TC68. 


IS020022 repozitorijum 


KATALOG POSLOVNIH PROCESA 


Poslovna područja 


u 


RECNIK PODATAKA 


je 

opisan 


Poslovni koncepti 


sa ^ 

rP od ^ ava ” I Z Baziran je na 

Д izvrsenje od ^_ | | _'_ 

je “ Koncepti poruka 

sastavljen 

. .. od _ 


Poslovne transakcije 


Tipovi podataka 


Zapisi o istoriji promena 


Slika 3. IS020022 repozitorijum sa rečnikom podataka 

ISO 20022 - UNIversal Financial Industry Message scheme (UNIFI) je internacionalni 
standard koji definiše ISO platformu za razvoj finansijskih standarda, prezentuje 
finansijskc poslovne modele i pripadajuće transakcije. U tu svrhu razvijen je i 
repozitorijum kao i skup standardizovanih šema poruka koje se nalaze na IS020022 
sajtu. Katalog poslovnih procesa i rečnik podataka prikazan na slici 3. jesu osnovni 
segmenti IS020022 repozitorijuma na kome počiva i sam standard. Rečnik podataka, 
prikazan na desnoj strani slike 3. sadrži: poslovne koncepte sa semantikom poslovnih 
procesa, koncepte pomka izgrađenih od kombinacija korišćenih objekata rečnika 
podataka i tipove podataka objekata koji nedvosmisleno određuju skup dozvoljenih 
vrednosti poslovnih elemenata i elemenata pomka. Katalog poslovnih procesa prikazan 
je na levoj strani slike 3. i organizovan je po poslovnim podmčjima. Poslovna podmčja 
(na primer poslovanje sa hartijama od vrednosti ili plaćanja) opisuju se korišćenjem 
poslovnih procesa koji su podržani odgovarajućim poslovnim transakcijama. Poslovne 
transakcije u katalogu poslovnih procesa zadaju se dijagramima toka. Dijagram toka 
sadrži jednu ili više pomka. Svaka pomka je zadata defmicijom koja je predstavljena i u 
obliku odgovarajuće IS020022 xsd šeme. Nabrojane artifakte IS020022 repozitorijuma 
možemo pronaći u dokumentaciji IS020022 standarda, unutar sekcije „Catalogue of 
UNIFI messages ” za svako poslovno podmčje i to u obliku formalnog opisa stmkture 
pomka i xsd šeme odgovarajuće pomke. 

2.4.4 Ograničenja standardizacije 

Standard predstavlja sporazum, a u najboljem slučaju, sporazum predstavlja kompromis. 
Pokušaj da se sve strane saglase oko istih procesa ili rečnika za sve njihove aktivnosti 
jeste težak, ako ne i nemoguć posao [30]. Moguće je postići saglasnost oko opštih 
metoda i prihvatljivih razlika za kreiranje i implementaciju poslovnih procesa. Do sada 
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je kreirano više standarda, koji se bave različitim fazama razvoja sistema elektronskog 
poslovanja, ali većina njih imala je ograničen uspeh. Veliki broj standarda je složen, što 
je dovelo do nerazumevanja njihovog značenja. Posledice su nekompatibilnost 
implementacija i pored činjenice da su standardi korišćeni. Problem sa korišćenjem 
standarda je i taj što ih je previše. Neki standardi nisu dobro delinisani ili se preklapaju 
sa drugim standardima, koje istovremeno predlažu konkurentske organizacije. 
Dešavanja oko standarda zbunjuju potencijalne korisnike i oni odlažu njihovo usvajanje 
i primenu, bar dok neki standard ne postane šire prihvaćen [173]. 

Problem može nastati i što se podržavanjem jednog standarda nenamemo sprečava 
prihvatanje nekog dmgog, altemativnog standarda. Standard nema operativni značaj sve 
dok se partneri ne usaglase kako da obavljaju posao na način dclinisan prihvaćenim 
standardom. Suština je da je posao, a ne standard, od kritične važnosti. Primena 
standarda je suštinski važna jer, osim obezbeđenja interoperabilnosti, uvodi pojedina 
rešenja, koja doprinose razvoju poslovanja [30]. Povoljna okolnost je da distribuirano 
računarstvo trenutno prolazi kroz period tranzicije, od vlasničkog pristupa ka pristupu 
zasnovanom na standardima. Ipak, veći deo današnje tehnologije još uvek je vlasnički, 
što uslovljava kupovinu različitih softverskih proizvoda od istog ispomčioca, da bi se 
omogućila integrisanost i kompatibilnost. 

Da bi se obezbedila neophodna interoperabilnost sistema elektronskog poslovanja, 
potrebno je koristiti novi koncept pri definisanja standarda. Postojeća standardizacija 
bila je prihvatljiva u vreme paketne obrade informacija. Aktuelni standardi su veoma 
kompleksni. Definišu samo razmenu podataka i način razmene podataka. Umesto toga, 
potrebno je da se kreiraju standardi koji će na jednostavan način definisati 
dokumentovanje: šta, kada i zašto je potrebno da se informacije razmenjuju u realnom 
vremenu i u elektronski prihvatljivom fonnat [153]. Neki od uočenih problema sa 
standardima za modelovanje elektronskog poslovanja su [103]: 

• Postojanje više standarda koji se preklapaju. 

• Postojanje više organizacija za definisanje standarda. 

• Postojanje različitih stavova o proširenju standarda. 

U situaciji kada se određeni standardi izabem i koriste, dešava se da se ne koriste 
adekvatno. Razlog su neprecizna tumačenja, a posledica su problemi pri ostvarivanju 
interoperabilnosti sa drugim sistemima i ograničenja kod njihovog naknadnog 
korišćenja, prilikom proširenja delova sistema. Korišćenje standarda može da ima veliki 
uticaj na interoperabilnost organizacija. Međutim, mnogi standardi još uvek su na 
konceptualnom nivou, zbog čega nije moguća jednostavna implementacija na 
operativnom nivou [232]. Zato je neophodan dalji rad na standardima u oblasti jezika i 
podržanih platformi, posebno na kreiranju i izvršavanju modela poslovnog procesa. 

2.5 Koncept interoperabilnosti 

Razvoj infonnaciono-komunikacionih tehnologija omogućio je prelaz sa samostalnih 
(stand alone) arhitektura na tzv. umrežene arhitekture informacionih sistema. Danas se 
umreženi IT sistemi oslanjaju na infrastrukturu World Wide Web -a (WWW) koja 
predstavlja tehnološku okosnicu elektronskog poslovanja omogućavajući različite 
poslovne procese i povezivanja unutar i van granica nekog sistema. Sa stanovišta 
tehnološke infrastrukture i softverske arhitekture sistemi predstavljaju heterogeno 
okruženje koje se velikom brzinom razvija. Sposobnost različitih informacionih sistema 
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da rade zajedno - interoperabilnost jeste ključni faktor uspešnog elektronskog 
poslovanja [118]. 

Pojam interoperabilnosti, u opštem slučaju, odnosi se na sposobnost dva sistema da 
međusobno razmenjuju informacije. Ima mnogo pokušaja da se definišc šta 
interoperabilnost znači. Neke od najcitiranijih definicija interoperabilnosti iz kojih se 
mogu izvesti zajedničke karakteristike interoperabilnosti jesu [124]: 

• sposobnost za saradnju. ( The ability to operate in conjunction) (Oxford 
Dictionarj, 2003); 

• sposobnost da dva ili više sistema, ili komponenata razmene informacije između 
sebe i da nakon toga te iste infonnacije mogu da koriste. ( The abilitv of two or 
more svstems or components to exchange information and. to use the information 
that has been exchanged) (IEEE, 1990); 

• sposobnost komunikacije, izvršavanja programa, ili prenosa podataka između 
različitih funkcionalnih jedinica na način koji zahteva da korisnici imaju malo ili 
nimalo znanja o jedinstvenim karakteristikama tih jedinica. ( The capabilitv to 
communicate, execute programs, or transfer data among various functional 
units in a manner that requires the user to have little or no knowledge of the 
unique characteristics of those units) (ISO, 2003); 

• stanje postignuto između komunikaciono-elektronskih sistema ili delova 
komunikaciono-elektronske opreme kada informacije ili usluge mogu da se 
razmenjuju direktno i na zadovoljavajući način između njih i/ili njihovih 
korisnika. ( The condition achieved among communications-electronics svstems 
or items of communications-electronics equipment when information or services 
can be exchanged directlv and satisfactorilv between them and/or their users) 
(dod, 2001); 

• sposobnost deljenja i razmene informacija korišćenjem zajedničke sintakse i 
semantike da bi se omogućile specifične funkcionalne veze aplikacija. (The 
abilitv to share and exchange information using common syntax and semantics 
to meet an application-specific functional relationship) (ISO, 2000); 

• sposobnost da dva ili više sistema ili komponenata razmenjuju i koriste deljene 
informacije. (The abilitv of two or more svstems or components to exchange and 
use shared information) (Open Group, 2000); 

• sposobnost sistema da pružaju i koriste servise-usluge od strane drugih sistema i 
da korišćenjem tako razmenjenih servisa omoguće efikasan zajednički rad. (The 
abilitv of systems to provide and receive services from other systems and to use 
the services so interchanged to enable them to operate effectively together) 
(Open Group, 2000); 

• sposobnost zasebnih i različitih organizacija da sarađuju u smeru postizanja 
zajednički korisnih i dogovorenih ciljeva, što uključuje razmenu informacija i 
znanja kroz poslovne procese koje podržavaju, putem razmene podataka između 
njihovih IKT sistema. (Interoperabilitv is the abilitv of disparate and diverse 
organisations 1 to interact towards mutually beneficial and agreed common 
goals, involving the sharing of information and knowledge between the 
organizations via the business processes they support, by means of the exchange 
of data between their respective information and communication technologv 
(ICT) svstems) (European Interoperability Framework - EIF v2.0, 2008) [65]. 
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Prema navedenim definicijama interoperabilnost karakterišu sledeća svojstva: 

• uključenost dva ili više entiteta (sistema, mreža, uređaja, aplikacija ili 
komponenata); 

• sposobnost za interakciju (npr. zajednički rad, međusobna komunikacija, 
razmena podataka, informacija i znanja, pružanje i prihvatanje servisa-usluga); 

• korisnici treba da imaju malo ili nimalo znanja o jedinstvenim karakteristikama 
entiteta koji rade zajedno; 

• smisao je u postizanju nekog cilja (efikasan zajednički rad, funkcionalno 
povezivanje različitih aplikacija, razmena i korišćenje informacija i usluga). 

Interoperabilnost zahteva određeni stepen kompatibilnosti između sistema koji 
razmenjuju informacije kako bi se minimizovale transformacije koje se zahtevaju kod 
razmene podataka i kako bi se obezbedili preduslovi za korektnu interpretaciju prenetih 
podataka. Idealna situacija je da su sistemi koji učestvuju u procesu međusobnog 
elektronskog poslovanja usaglašeni sa standardnima iz odgovarajućeg aplikacionog 
domena. Međutim, u praksi je to uglavnom nemoguće ostvariti zbog brzine tehnoloških 
promena, nedostatka univerzalno prihvaćenih standarda, postojanja zastarelih sistema ili 
jednostavno zbog postojanja autonomije svakog od sistema. Zahtevana kompatibilnost 
se može ostvariti korišćenjem apstrakcija kojima će se sakriti kompleksnost i 
implementacioni detalji. 

Da bi se obezbedilo efikasno elektronsko poslovanje sistema i pružanje usluga 
korisnicima, neophodno je obezbediti nesmetan tok i razumevanje informacija. Za 
realizaciju tog zahteva potrebno je definisati tehničke specifikacije i rešenja za 
ostvarivanje međuoperativnosti i koherentnosti informacionih sistema. Pored toga, 
potrebno je obezbediti uniforman način komunikacije između aplikacija sistema i 
spoljnih, pre svega poslovnih sistema u okviru zemlje, kao i na međunarodnom nivou. 

Definisanje tehničkog okvira za razmenu podataka i implementacija usvojenih 
specifikacija u aplikacijama omogućila bi efikasnu razmenu podataka između bilo kojih 
aplikacija koje podržavaju date specifikacije direktno, i bez potrebe bilo kakvog 
specifičnog prilagođenja aplikacija. Time bi se postigao cilj - nesmetan protok i 
razumevanje infonnacija kroz celi sistem, što bi efektivno značajno povećalo vrednost 
instaliranih aplikacija. 

Često se pojam „interoperabilnost" pogrešno izjednačava sa pojmom „integracije 
sistema". Integracija u okviru preduzeća odnosi se na: fizičku integraciju (povezivanje 
uređaja i mašina preko računarskih mreža); integraciju aplikacija (integracija 
softverskih aplikacija i sistema baza podataka) i poslovnu integraciju (koordinacija 
funkcija za upravljanje i nadgledanje poslovnih procesa). Sa stanovišta povezanosti, 
integrisani sistemi čvrsto su povezani, odnosno njihove komponente međusobno su 
zavisne i ne mogu biti izdvojene. Za razliku od integrisanih sistema, interoperabilni 
sistemi slabo su povezani [159]. Dva integrisana sistema implicitno su interoperabilna, 
međutim, dva interoperabilna sistema ne moraju biti istovremeno i integrisana [196]. 

Da bi se razumela priroda interoperabilnosti, potrebno je još naglasiti da 
interoperabilnost nije nešto što se može trajno i u potpunosti postići. Promena i 
unapređenje tehnologija, poslovnih procesa, razvoj standarda i sl. utiču na to da se na 
interoperabilnosti stalno mora raditi i možemo samo govoriti da je u određenom slučaju 
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postignuta veća ili manja interoperabilnost sistema. Prema ovom shvatanju, za 
interoperabilnost se može reći da je stalni proces koji treba da obezbedi da se 
maksimizira mogućnost za razmenu i ponovno korišćenje infonnacija unutar nekog 
sistemima i između različitih sistema [123]. 

Interoperabilnost je i preduslov i olakšavajući faktor sistemima za cfikasno pružanje 
usluga kojim se rešava potreba za: 

• saradnjom između sistema i ostalih organizacija i institucija na nacionalnom i 
međunarodnom nivou; 

• razmenom informacija radi ispunjenja zakonskih uslova ili političkih obaveza; 

• razmenom i ponovnom upotrebom informacija radi povećanja administrativne 
efikasnosti i smanjenja administrativnih opterećenja na građane i poslovne 
subjekte. 

Od područja poslovanja i ciljane grupe korisnika zavise i standardi koji su od interesa za 
interoperabilno elektronsko poslovanje. Postoji niz okvira za interoperabilnost od kojih 
je svaki baziran na 10-20 arhitektonskih principa [175]. 

Okvir interoperabilnosti može se definisati kao skup standarda i smemica koji opisuje 
način na koji su se organizacije usaglasile ili bi trebalo da se usaglase da će uzajamno 
poslovati. Okvir interoperabilnosti nije statički dokument, već se sa vremenom mora 
prilagođavati promenama tehnologija, standarda i administrativnih zahteva [63]. 

Referentni dokument za podmčje interoperabilnosti u Evropi je Evropski okvir za 
interoperabilnost EIF 1.0 [63] koji je napravljen u svrhu koordinisanja IDABC programa 
(.Interoperable Deliveri of European eGovernment Services to pubiic Administrations, 
Businesses and Citizens). Na snazi je verzija 1.0 iz novembra 2004, a intenzivno se 
raspravlja o usvajanju verzije 2.0, koju je sredinom 2007. pripremio Gartner [64], a koja 
je predstavljena u decembru 2010. 

Osim Evropskog okvira za interoperabilnost postoji niz nacionalnih okvira za 
interoperabilnost u Evropi i svetu koji sadrže konkretne prepomke važećih standarda. 
Neki od njih su: HKSARG IF (Hong Kong) [91], AGTIF (Australija), eGIF (Velika 
Britanija) [217], EstlF (Estonija) [59], Nora (Nizozemska) [62], OIO (Danska) [50], 
FEA (Sjedinjene Američke Države) [226] itd. Agendom Plus za elektronsku 
Jugoistočnu Evropu ( eSEE Agenda+) interoperabilnost je prepoznata kao jedna od 
ključnih aktivnosti u okvim oblasti Jedinstveni informacioni prostor jugoistočne 
Evrope. U vezi sa tim, obaveza zemalja regiona je usvajanje nacionalnog okvira 
interoperabilnosti za administracije, kako bi se osigurala kompatibilnost i saradnja 
sistema, procesa i ljudskih resursa i kako bi se omogućio nesmetano poslovanje na 
panevropskom nivou i pmžili servisi usmereni na korisnike [58]. 

Prvi nivo interoperabilnosti obuhvata tehničke aspekte povezivanja informacionih 
sistema kao što su specifikacije interfejsa, usluge povezivanja, usluge integracije 
podataka, predstavljanje i razmena podataka itd. Tehnička interoperabilnost treba da se 
obezbedi kada je god to moguće korišćenjem opšteprihvaćenih i otvorenih standarda 
usvojenih od strane priznatih organizacija za standardizaciju [63]. U okvim tehničke 
interoperabilnosti mogu se razlikovati: komunikaciona interoperabilnost i sintaksna 
interoperabilnost. Komunikaciona interoperabilnost zavisi od infrastmkture i 
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standardizovanih protokola koji su unapred precizno delinisani (npr. enkapsulacija, 
okviri, algoritmi za proveru grešaka itd.). Ova interoperabilnost može biti ostvarena 
primenom OSI (Open Systems Interconnection) referentnog modela koji definiše 
komunikacione slojeve i protokole pomoću kojih mogu da komuniciraju različiti 
računari i sistema, slika 4. 



Tehnička interoperabilnost 


Sintaksna interoperabilnost 


Komunikaciona 
interoperabilnost (OSI) 


Slika 4. Tri osnovna nivoa interoperabilnosti 

Sintaksna interoperabilnost obezbeđuje razmenu sadržaja između različitih sistema ili 
softverskih komponenata nezavisno od jezika u kome su iste implementirane, runtime 
okruženja i drugih tehnoloških razlika. Sintaksna interoperabilnost služi premošćivanju 
jaza između formata podataka, standarda jezika, operativnih sistema i hardverskih 
platformi. Ostvaruje se uspostavljanjem i prihvatanjem zajedničkog formata (sintakse) 
prezentacije podataka. Najrašireniji sintaksni standard za ostvarivanje ovog nivoa 
interoperabilnosti jeste XML jezik za prezentaciju podataka. Semantička 
interoperabilnost je sposobnost organizacije i njihovih informacionih sistema da otkriju 
zahtevane informacije, eksplicitno opišu značenje podataka koje žele da dele sa drugim 
organizacijama i procesiraju informacije u skladu sa njihovom svrhom. 

Problem interoperabilnosti javlja se kada se dva poslovna sistema ili više poslovnih 
sistema, nađe u međusobnoj vezi. Postojeći softverski sistemi sastavljeni su od 
aplikacija, koje su razvijane u različitim periodima, od strane različitih razvojnih 
timova, koji su najčešće radili bez stvame koordinacije. Pored toga, za razvoj aplikacija 
korišćene su različite tehnologije. U većini slučajeva, nove aplikacije kreiraju se 
korišćenjem, u tom momentu, najnovijih tehnologija, često bez kritičkog odnosa prema 
neophodnosti implementacije baš najnovijih tehnologija. Zaboravlja se da nova, 
trenutno aktuelna tehnologija postaje zastarela kroz određeni vremenski period. Takođe, 
većina ranijih aplikacija nije dizajnirana da komunicira sa drugim aplikacijama. 
Korišćenje komercijalnih softverskih paketa povećava problem s obzirom na to da su 
dizajnirani da određeni problem rešavaju uopšteno. U toj situaciji, za povezivanje 
aplikacija potrebno je kreirati prilagođene linkove i interfejse. 

Posmatrana na ovaj način, interoperabilnost je cilj koji treba dostići. Iz praktične 
perspektive, bez obzira na brojnu literaturu koja se bavi problemima interoperabilnosti, 
istraživanja su još uvek u ranoj fazi. Neki od problema, koje je potrebno i dalje rešavati, 
jesu [173]: 
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• korišćenje standarda ne garantuje uvek postizanje interoperabilnosti; 

• primena principa projektovanja ne garantuje uvek postizanje interoperabilnosti; 

• sveobuhvatno rešavanje zaštite informacija i bezbednosna pitanja u celoj 
organizaciji, koja su od ključnog značaja za obezbeđivanje pouzdanih 
elektronskih poslovnih odnosa i saradnje; 

• pitanja izvan domena tehnike, kao što su: komunikacija na kulturnom i ljudskom 
nivou i interakcije računara i domena specifičnih znanja, dokazano je da mogu 
postati prepreka u postizanju interoperabilnosti; 

• potreba da se analizira i oceni interoperabilnost sama po sebi; 

• brz razvoj tehnologije može da smanji stepen interoperabilnosti sistema ukoliko 
se zahtevi za interoperabilnošću ne razmatraju na nivou dizajna. 

Posmatrano iz različitih perspektiva, postoji nekoliko načina za postizanje 
interoperabilnosti. Opšteprihvaćeni načini za rešavanje problema interoperabilnosti su: 
standardi, okviri za interoperabilnost, okviri za arhitekturu informacionih sistema 
preduzeća, semantičke tehnologije zasnovane na ontologijama i servisna orijentacija. 

2.6 SOA i organizađje za standardizaciju elektronskog poslovanja 

Modelom vođena integracija ( model driven integration) je pojam koji označava 
automatizovanu ili poluautomatizovanu integraciju heterogenih sistema uz pomoć 
apstraktnih modela opisanih najčešće u UML-u. Osnovna ideja je postojanje 
infrastrukture koja skladišti standardizovane opise informacionih sistema i korišćenje 
predefinisanih interfejsa, koja bi iz takve infrastrukture mogla prikupljati i obrađivati 
podatke i na taj način prikupiti dovoljno znanja o svojoj okolini kako bi automatska ili 
poluautomatska integracija s okolnim aplikacijama i sistemima bila omogućena. 
Pokretač integracije je deljenje podataka, a da bi se podaci mogli razmenjivati i deliti 
oni moraju odgovarati zajedničkom modelu. Taj model pružaju upravo metapodaci. 
Metapodaci se definišu kao podaci koji opisuju druge podatke, najčešće u kontekstu 
elemenata informacionih sistema. U početku su metapodaci korišćeni za stvaranje 
dokumentacije projekata. Globalnim prihvatanjem UML standarda metapodaci su 
postali osnovni alat za modelovanje sistema, tj. stvaranje apstraktne, ali precizne slike 
sistema. Metapodaci su i sredstvo integracije heterogenih sistema. Jedan od problema s 
integracijom je činjenica da još uvek nema široko prihvaćene metodologije koja stvara 
uspešnu sinergiju tehnologija sa potencijalima integracije uz pomoć normalizovanih 
metapodataka. Implementacija arhitekture SOA ( Service Oriented Architecture - 
servisno orjentisana arhitektura) [126] zasnovane na vebu i XML-u najčešće se izvodi 
na najnižem metanivou, tj. modeliranjem sistema u zavisnosti of konkretne poslovne 
okoline i zadatog problema, s minimalnim osvrtom na potencijalno dostupne 
metapodatke koji opisuju zadate komponente sistema. Upravo metapodaci najčešće u 
sebi sadrže informacije ključne za integraciju sistema, pogotovo s obzirom na dizajn 
komponenata sa kojima bi se ta integracija sprovela. Servisno orijentisana arhitektura 
(SOA - Service Oriented Architecture) je pojam koji najčešće označava infrastruktumi 
model sistema čija je funkcionalnost zasnovana na međusobno interoperabilnim 
„uslugama", tj. funkcionalnim entitetima koji kolaboriraju kroz zajednički definisane 
standarde. Egzaktna SOA definicija ne postoji, pa čak ni konsenzus oko toga da li 
pojam označava samo paradigmu, model sa svojstvima i smernicama kojih se pri 
implementaciji treba pridržavati ili čak strogo definisani skup tehnologija koje zajedno 
čine okosnicu servisno orijentisane arhitekture. Ključne karakteristika sistema SOA, 
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koje se najčešće spominju u svim definicijama, jesu modulamost, distribuiranost i slaba 
povezanost. 

Poruka se u servisno orjentisanoj arhitekturi definiše kao „nezavisna jedinica 
komunikacije“. To znači da entitet koji pošalje poruku više nema kontrolu nad njom niti 
nad aktivnostima koje će se nad njom kasnije dogoditi. Analogno adresi na pošiljci, 
poruka u sistemu servisno orjentisane arhitekture mora sadržati informacije pomoću 
kojih se ona može usmeriti na željenu adresu i omogućiti primanje odgovora ako je to 
potrebno. Principi dizajna usluga i pomka predstavljaju vrlo bitan segment pojma 
servisno orjentisane arhitekture. Neki od tih principa su: 

• slaba povezanost - radi se o uspostavljanju takvog tipa odnosa - između samih 
usluga, ali i usluga i korisnika - koji minimizira međuzavisnost i potrebna je 
samo svest o međusobnom postojanju; 

• ugovor o komunikaciji - svaka usluga mora se prilagoditi definisanim 
standardima, tj. ugovom o komunikaciji, čiji se detalji mogu opisati na određeni 
način u specifikaciji usluge; 

• autonomija - usluge imaju apsolutnu kontrolu nad poslovnom logikom koju 
sadrže u sebi; 

• apstrakcija - sve infonnacije koje usluga pmža o sebi nalaze se u specifikaciji 
usluge; sama; 

• implementacij a j e sakrivena od okmženj a; 

• ponovna iskoristljivost - usluga može biti deo većeg broja poslovnih procesa, a 
njena funkcionalnost ne mora biti prilagođena samo posebno odabranoj prilici, 
već se kao univerzalna može prema potrebi ponovno koristiti; 

• modularnost - skupovi usluga moraju se modularno kombinovati u poslovnim 
procesima i/ili šire definisane usluge; 

• nepostojanje stanja - usluga mora minimizirati informacije koje su specifične za 
pojedini slučaj upotrebe; 

• mogućnost pronalaženja usluge - usluge se stvaraju tako da se mogu opisati 
preko definisanih mehanizama kako bi se informacije o njima mogle na 
adekvatan način pronaći i kako bi im se moglo pristupiti. 

Ono što je ključno naglasiti jeste činjenica da je pojam uslužno orjentisane arhitekture 
tehnološki nezavisan - principi koje definiše su generički i za implementaciju 
funkcionalnosti je potrebno odabrati konkretnu platfonnu. 

U šezdesetim godinama prošlog veka razvijen je jezik zvan SGML ( Standard 
Generalized Markup Language). Originalna ideja razvoja ovog jezika bila je stvaranje 
načina reprezentacije infonnacije koju će kompjuteri moći da interpretiraju i koji bi bio 
relativno postojan s obzirom na izmenu i evoluciju tehnologije. Nakon prihvatanja od 
strane organizacije ISO ( International Organization for Standarization ) jezik je vrlo 
dobro prihvaćen kao metajezik pomoću koga se mogu definisati dokumenti zasnovani 
na oznakama za različite primene u tadašnjoj informatičkoj tehnologiji. Navedena ideja 
markup jezika uvodi anotaciju informacije unutar dokumenta dodatnim podacima koji 
mogu poslužiti kao metapodaci, uputstva za način prikaza i drugo. Najpopulamiji 
naslednici jezika SGML su jezik HTML ( HyperText Markup Language) i XML 
(< eXtensible Markup Language). Specifikacija XML-a predstavlja pojednostavljeni 
podskup SGML-a, dizajniran na način da omogući implementaciju jednostavnijih 
parsera. XML veliku populamost dostiže sredinom devedesetih godina kada se Internet 
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polako počinje prepoznavati kao idealna platforma za moderno elektronsko poslovanje. 
Pomoću XML-a aplikacije imaju mogućnost uobličavanja poslovnih infonnacija na 
platformski neutralan način prilagođen i ljudskom razumevanju (pošto je zasnovan na 
tekstu a ne binamom kodiranju) i kompjuterskoj obradi (zbog strogo delinisane 
sintakse). Dodatne specifikacije kao što je XML Schema (koja omogućuje delinisanjc 
ograničenja nad stmkturom XML dokumenata i tipovima podataka koje sadrže) i XSLT 
(koja omogućuje transformaciju XML dokumenata iz jedne u drugu XML stmktum 
dokumenta, ali i u druge formate) još više pospešuju univerzalno prihvatanje XML-a. 
Godine 2000. organizacija W3C (World Wide Web Consortium) prima zahtev za 
ratilikacijom specifikacije nazvane SOAP (Sitnple Object Access Protokol - jednostavni 
protokol za pristup objektima). Prvobitna namena ove specifikacije bila je 
standardizacija postupka poziva udaljenih metoda (RPC - Remote Procedure Call ). 
Glavna ideja je kodiranje parametara poziva u XML dokument, transport dokumenta, te 
dekodiranje na strani primaoca u oblik koji primalac može razumeti. 

Proizvođači softvera su uočili potencijal ovog standarda koji uz jezik XML i intemet 
protokole predstavlja kvalitetan gradivni blok za razvoj distribuiranih aplikacija za 
elektronsko poslovanje zasnovanih na vebu. Ovaj koncept nazvan je veb-servis. Ključni 
segment veb-servisa bio je javni interfejs kome se može pristupiti preko intemet 
protokola. Zbog toga je jedna od prvih inicijativa bila razvoj jezika za opis tog 
interfejsa, odnosno specifikacija WSDL ( Web Services Description Language - jczik za 
opis usluga veba). Iako se veb-servisi ne ograničavaju na SOAP protokol, on je ipak 
postao jedan od najšire prihvaćenih protokola u konkretnim implementacijama. 

Treća komponenta (pored komunikacijskog protokola i standardizacije načina opisa 
usluga) koja je uokvirila specifikaciju veb-servisa jeste specifikacija UDDI (Universal 
Description, Discoverv and Integration). Ova specifikacija pmžila je način stvaranja 
registara u kojima se mogu čuvati i taksonomski organizovati opisi veb-servisa. 
Softverska industrija ga za sada nije preterano dobro prihvatila tako da arhitektura SOA 
danas još uvek registar usluga smatra uglavnom opcionom komponentom sistema. 
Rešenja za razmjenu pomka (message-oriented middleware ili MOM) uključila su 
protokol SOAP u svoja rešenja zajedno s postojećim komunikacionim protokolima koja 
su koristila; veliki poslovni sistemi razvili su vlastita prilagođena rešenja zasnovana na 
veb-servisima kao altemativu EDI (Electronic Data Interchange) standardu; veb-servisi 
su uzrokovali veliku popularnost modela nove arhitekture za realizaciju informacionih 
sistema - servis orjentisanu arhitektum ili SOA. 

Sve modeme implementacije SOA oslanjaju se na SOAP kao osnovni komunikacioni 
protokol; postupak modelovanja poslovnih dokumenata u pripadne XML dokumente i 
njihove XSD sheme sada često mora uzimati u obzir i postojanje SOAP-a i njegovih 
karakteristika. SOA stavlja naglasak na razmenu pomka zasnovanu na dokumentima 
(document-stvle messaging), što se razlikuje od početne primene Za SOA su pogodne 
kontekstualno opšime inteligentne pomke umesto usko definisanih ciljno usmerenih 
pomka kao kod poziva udaljenih metoda. Pomka treba imati sposobnost samostalne 
egzistencije, mora da sadrži dovoljno informacija kako bi olakšala obradu kroz usluge i 
tako omogućila autonomiju usluga i isključila potrebu za čuvanjem njihovog stanja. 
Karakteristike i zahtevi savremenih SOA diktiraju proširenje specifikacije veb-servisa 
kako bi se ti zahtevi mogli ispuniti; rezultat ove inicijative jeste nastanak tzv. WS- 
proširenja (WS -extensions) - skupa specifikacija koje veb-servisima dodaju nove 
mogućnosti kao npr. mehanizme sigumosti, razmene metapodataka i slično [170]. 
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Nove tehnologije elektronskog poslovanja obavezno uključuju kvalitet usluge (QoS - 
Quality of Service ). Zahtevi mogu biti: sigumosni mehanizmi, pouzdanost ispomke ili 
objavljivanje greške na adekvatan način, performanse sistema u skladu s očekivanjima, 
tj. informatička stmktura koja ne sme inhibirati sprovođenje poslovnih zadataka u 
zadatim vremenskim okvirima, transakcijske mogućnosti tj. zaštita integriteta skupa 
poslovnih procesa koji se moraju ili uspešno obaviti ili potpuno obustaviti. 

W3C ( World Wide Web Consortium) je internacionalna organizacija za donošenje 
standarda osnovana 1994. koja se smatra jednim od glavnih učesnika u transformaciji 
World Wide Web-a iz infrastmkture povezanih radnih stanica u globalni semantički 
medijum za razmenu informacija. Uspeh W3C-a započinje izdavanjem spccifikacijc 
jezika HTML bez koga je Intemet današnjice nezamisliv. Kada se krajem prošlog veka 
počeo uočavati potencijal Intemeta kao glavne infrastmktume tehnologije za 
omogućavanje modernog elektronskog poslovanja, W3C donosi ključne standarde koje 
bi takva rešenja podržali: specifikaciju XML, te srodne specifikacije, kao što su XML 
šema i XSLT. Konačno, W3C je izdao specifikacije ključne za implementaciju usluga 
veba - norme SOAP i WSDL. W3C je poznata kao organizacija čiji standardi prolaze 
kroz mnoge revizije i recenzije koje se javno objavljuju kako bi se dobilo što više 
korisnih povratnih informacija. To često ima za posledicu da se standardi često čekaju i 
po nekoliko godina. 

OASIS je internacionalna organizacija zadužena za norme poznata po preuzimanju WS- 
BPEL specifikacije, nonni ebXML i doprinosu pri nastanku specifikacije UDDI. 
Organizacija OASIS doprinela je razvoju i proširenju XML-a kao standarda, a trenutni 
veliki projekt jeste normizacija jedne od najvažnijih komponenti specifikacija proširenja 
veb-servisa - okvira WS-Security zaduženog za sigurnosne mehanizme. 

Dok W3C najčešće preuzima ulogu razvoja bazičnih standarda, OASIS se primarno 
usredsređuje na proširenje tih standarda i njihovo vertikalno prilagođavanje različitim 
industrijskim granama. Standardi gmpe OASIS imaju kraći rok do objave od W3C 
Standarda. 

Organizacija WS-I osnovana je sa ciljem definisanja odgovarajućeg skupa standarda, 
čijom se primenom omogućava interoperabilnost elektronskog poslovanja sistema koji 
se pridržavaju prepomka koje daje WS-I. Počev od 2002. godine, kada je osnovana, ova 
organizacija ima podršku od 200 organizacija uključujući neke od najvećih proizvođača 
softvera koji se bave implementacijama arhitektura SOA . 

WS-I jc najpoznatija po izdavanju tzv. Osnovnog profila ( Basic Profile) - dokumenta 
koji predlaže skup standarda koji bi trebalo koristiti kako bi se osigurao maksimalan 
mogući stepen interoperabilnosti unutar sistema. Ovaj dokument, između ostalog, sadrži 
i prepomku tačno određenih verzija standarda WSDL, SOAP, UDDI, XML i XML Sheme 
i kao takav ima važnu ulogu kod prilagođavanja arhitekture SOA na konkretna poslovna 
rešenja (organizacije koje vrše prilagođavanja sistema obično naznače da je njihova 
adaptacija „saglasna Osnovnom Profilu"). Nedavno je izdato i proširenje Osnovnog 
Profila nazvano Osnovni sigurnosni profil ( Basic Security Profile) koji sadržava - prema 
mišljenju organizacije WS-I - skup najvažnijih tehnologija vezanih uz sigurnost XML- a i 
veb-usluga. Uz navedene Profile WS-I nudi niz primera implementacija i alata koji 
testiraju saglasnost sa Osnovnim profilom. 
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U razvoju standarda značajnu ulogu imaju veliki proizvođači softvera kao što su Sun, 
IBM [94], Oracle, Microsoft, Hewlett-Packard, Canon, Verisign itd. Interesi i doprinosi 
velikih organizacija za navedene standarde doveli su do nekih zanimljivih uticaja na 
oblik samih standarda i njihovu prihvaćenost, pogotovo ako se uzme u obzir da se 
usprkos zajedničkom cilju interoperabilnosti, ovde radi o konkurentskim organizacijama 
od kojih svaka ima svoje interese vezane za tržište softvera. 

Uloga velikih kompanija je dvojaka. S jedne strane oni sarađuju u razvoju standarda, 
dok s druge prihvaćenost njihovih rešenja utiče kako na uspešnost standarda tako i na 
profit same kompanije. Zbog toga je uravnoteženje i optimizacija standarda sa politikom 
kompanije i zahtevima tržišta osnovni strateški zadatak svake kompanije uključene u 
saradnju. Nije nepoznat slučaj da nekoliko velikih kompanija osnuje vlastitu koaliciju i 
tako proširi svoj uticaj unutar nezavisnih organizacija, iako se takve koalicije najčešće 
koncentrišu na pojedinu ciljnu specifikaciju od koje sve imaju zajedničku korist (npr. 
IBM, Microsoft i BEA su zajedničkim snagama izrazito podržavali razvoj i zaključenje 
više specifikacija vezanih za tehnologiju proširenja veb-servisa - WS-extensions, kako bi 
njihova najnovija rešenja mogla implementirati neke ključne mehanizme koji trenutno 
nedostaju softverskim rešenjima zasnovanim na veb-uslugama). Ponekad takve koalicije 
deluju kontraproduktivno - npr. Sun i Oracle su zajedno izneli specifikaciju za sigurnu 
isporuku poruka nazvanu WS-Reliability, da bi Microsoft i IBM u isto vreme izdali svoju 
specifikaciju za identičnu svrhu nazvanu WS-ReIiableMessaging. Ovakvi primeri 
pokazuju da autoritet organizacija za standarde još uvek nije toliko uticajan da bi mogao 
garantovati jednaku poziciju svima na tržištu, otvorene standarde i interoperabilnost. 
Tržišna politika, konkurencija i uticaj velikih kompanija iz tih razloga će uticati na broj, 
oblik i prihvaćenost otvorenih standarda i interoperabilnost modemih rešenja 
zasnovanih na arhitekturi SOA . 

2.7 Sigurnost elektronskog poslovanja 

U procesu elektronskog poslovanja mora se obezbediti okvir za siguran rad sa 
informacijama. Ovo podrazumeva da se moraju preduzeti sve mere zaštite u 
infonnacionim sistemima kako bi se minimizirala mogućnost gubitka informacija ili 
njihovo neovlašćeno menjanje/korišćenje, što bi u određenim slučajevima moglo da 
izazove nesagledive posledice. Zbog toga je potrebno razviti rešenja i definisati 
postupke i mere koje će obezbediti informaciono-komunikacionu sigumost i stvoriti 
mehanizme za njihovu primenu. Ovo je od ključnog značaja jer se time stvaraju uslovi 
da su elektronske transakcije pouzdane, zaštićene i sa zahtevanim stepenom 
poverljivosti. 

Preterano i neumereno fokusiranje na sigurnost može, s dmge strane, da rezultuje 
rešenjima koja su suviše rigidna, komplikovana i skupa i koja mogu predstavljati 
prepreku za razvoj i primenu novih tehnologija. Primena i korišćenje novih 
infonnacionih tehnika i proizvoda, kao i komunikacionih mreža jeste dinamički proces, 
što zahteva permanentno i sistematsko sagledavanje mogućnosti pristupa administracije 
kritičnim resursima, kvaliteta servisa i zaštitnih mehanizama. Dakle, neophodno je 
permanentno procenjivati rizike s jedne strane i sigurnost sistema s dmge strane i tražiti 
izbalansirano rešenje. Sigurnosni mehanizmi takođe moraju da uzmu u obzir Zakon o 
zaštiti ličnih podataka, i da onemoguće neautorizovano korišćenje ličnih podataka koji 
su predmet zakonske zaštite. 
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Postoje različite podele koje identifikuju najvažnije zahteve koje jedan sistem mora 
ispuniti da bi se mogao smatrati sigurnim. Prema jednoj od najčešće primenjivanih 
podela, najvažniji sigurnosni aspekti bilo kog informacionog sistema su: poverljivost, 
integritet i dostupnost. 

Poverljivost podrazumeva garantovanje da resursima mogu pristupiti samo i isključivo 
autorizovani korisnici. To znači da samo oni koji treba da imaju pristup nekom resursu 
zapravo i mogu da mu pristupe, s tim da se pristup ne ograničava na pregledanje, 
čitanje, mijenjanje i slično, već i otkrivanje postojanja resursa. 

Integritet podrazumeva da resursi mogu da budu promenjeni samo od strane 
autorizovanih korisnika ili samo na autorizovan način. U ovom kontekstu, promena 
uključuje kreiranje, menjanje, promenu statusa i brisanje resursa. 

Dostupnost podrazumeva da resursi moraju biti dostupni legitimnim korisnicima, ako 
imaju odgovarajuća pristupna prava, i ako resursima pristupaju na dobro definisan 
način. 

Da bi se obezbedili ovi sigurnosni aspekti, potrebno je obezbediti rešenja za utvrđivanje 
identiteta korisnika (identifikacija i autentifikacija) i prava korisnika (autorizacija). 

Računarske mreže zasnovane na TCP/IP (Transmission Control Protocol/Internet 
Protocol) skupu komunikacijskih protokola u svom izvornom obbku ne vode računa o 
zaštićenom prenosu podataka, kao ni o problemima utvrđivanja autentičnosti pošiljaoca. 
TCP/IP komunikacijski protokol ima ugrađene mehanizme za otkrivanje i ispravljanje 
grešaka pri prenosu podataka, ali o problemima zaštite privatnosti i tajnosti podataka ne 
vodi računa. Drugim rečima, infrastruktura Interneta i svih mreža za zasnovanih na 
TCP/IP skupu protokola garantuje pouzdan prenos podataka s izvorišta na odredište 
(koliko je to moguće), ali podaci koji se šalju mogu biti vidljivi svakome ko je u 
mogućnosti da presretne mrežnu komunikaciju. Podaci koji se prenose mrežom 
podložni su promenama od strane napadača, pa je time narušena izvomost i 
verodostojnost podataka. Za svaku ozbiljniju primenu komunikacije putem Interneta i 
ostalih TCP/IP mreža ovi uslovi nisu prihvatljivi, pa su razvijene metode kriptovanja za 
zaštitu podataka pre nego što se oni pošalju kroz mrežu. 

2.7.1 Sigurnost i interoperabilnost 

Interoperabilnost različitih sistema znači da se oni lako mogu povezati i da lako mogu 
sarađivati. Da bi saradnja i interoperabilno elektronsko poslovanje različitih sistema bili 
uspostavljeni, između ostalog, potrebno je te sisteme „otvoriti” jedne prema dmgima. 
To otvaranje u praksi najčešće je povezano otvaranjem prolaza u sigurnosnoj 
infrastmkturi za legalne korisnike (koji se ponašaju na propisan način). Svako otvaranje 
prolaza znači i namšavanje sistema bezbednosti i povećanje ranjivosti tog sistema. Sa 
dmge strane, veći stepen bezbednosti dovodi do zatvaranja sistema i otežanog 
poslovanja. Dmgi problem je što sistemi zaštite različitih poslovnih sistema mogu biti 
toliko različiti da njihova međusobna saradnja može doći u pitanje. Iz tog razloga kada 
se želi uspostaviti interoperabilno elektronsko poslovanje, mora se voditi računa i o 
interoperabilnosti sistema zaštite koji treba da se bazira na opšteprihvaćenim 
standardima. 
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Kriptografske metode mogu da obezbede poverljivost i integritet poruke, ali ako 
korisnik kome je upućena šifrirana poruka nije u stanju da je i dešifruje, ceo postupak 
postaje besmislen i u praksi se često dešava da se poruke razmenjuju u čitljivom obliku. 

Infrastruktura javnih ključeva (PKI - Pnblic Кеу Infrastructure) može da obezbedi 
sistem za utvrđivanje identiteta korisnika, ali ako svaka organizacija izgrađuje sopstveni 
PKI bez uspostavljanja međusobnog poverenja, pojavljuje se problem sa 
autentifikacijom. Mi danas umesto jedne identifikacione kartice imamo više 
identifikacionih kartica: ličnu katu, karticu za svaku banku sa kojom sarađujemo, 
personalizovanu karticu za kupovinu u lancu supermarketa itd. Za postizanje visoke 
interoperabilnosti bilo bi potrebno da se uspostavi okruženje u kome sertifikati izdati 
kod jednog provajdera mogu biti provereni i u drugom sertifikacionom sistemu. 

Razlozi zbog kojih veći stepen interoperabilnosti može da utiče na niži stepen 
bezbednosti su: 

• tehnološki - strane u elektronskom poslovanju objektivno ne mogu da zasnivaju 
poslovanje na istim standardima zbog heterogenosti infonnacionih sistema; 

• politika poslovanja - postoji tehnološka mogućnost uspostavljanja sigumog 
interoperabilnog poslovanja, ali nije postignut dogovor o primeni odgovarajućih 
standarda; 

• nepostojanje odgovarajućih standarda; 

• ljudski faktor, nemarnost, neznanje i drugi slični faktori. 

2.7.2 Model zaštite resursa 

Zaštita resursa je proces održavanja prihvatljivog nivoa rizika, a ne završno stanje, tj. 
nije konačni proizvod. Organizacija ili institucija ne može se smatrati u potpunosti 
zaštićenom ni u jednom trenutku, čak ni neposredno posle izvršene provere usklađenosti 
s vlastitim sigurnosnim pravilima. Jednostavno rečeno, rizik uvek postoji, dok je 
stopostotnu zaštitu nemoguće postići. Postupkom zaštite resursa teži se smanjenju rizika 
na najmanju moguću meru. 

Veće ulaganje u sigumost smanjuje izloženost resursa riziku. S druge strane, ono izlaže 
vlasnika resursa većim troškovima i smanjuje profitabilnost. Zato je veoma značajno da 
se odredi tačka u kojoj se postiže ravnoteža između ulaganja u sigumost i postignutih 
efekata. 

Treba takođe imati u vidu sledeće: kao i u dmgim sistemima i oblastima, sigumosni 
mehanizmi ili procedure vrlo često smanjuju udobnost rada ili pogoršavaju performanse 
sistema. Kratkoročno gledano, to može negativno uticati na opšte efekte rada; 
dugoročno, ove mere pozitivno utiču na uspeh u radu. To se ogleda i kroz materijalne 
pokazatelje, i kroz pokazatelje koji nisu direktno materijalni, kao što su rast ili gubitak 
reputacije, tj. ugleda, zavisno od toga da li se incidenti dešavaju ili ne. 

Najvažniji faktori uspeha su sledeći: 

• aktivnosti koje se odnose na ceo sigumosni proces moraju biti zasnovane na 
zahtevima posla i moraju ih voditi poslovna mkovodstva; 

• neophodno je dobro razumeti rizike od potencijalnih pretnji i ranjivosti sistema; 

• osnovni koncepti zaštite moraju biti izloženi svim rukovodiocima i zaposlenima 
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kako bi svi shvatili koliko je zaštita važna; 

• kompanijska ili institucionalna uputstva za primenu pravila i standarda zaštite 
moraju se dostaviti svim zaposlenima i svim saradnicima koji nisu stalno 
zaposleni. 

Proces zaštite (slika 5.) zasniva se na četiri osnovna koraka [171]: procena, zaštita, 
otkrivanje i odgovor. U ovom modelu, neki autori koriste izraz ,,planiranje“ ( planning) 
umesto izraza ,,procenjivanje“, a izraz ,,sprečavanje“ ili ,,prevencija“ (preventior) 
umesto izraza ,,zaštita“. 



Slika 5. Model procesa zaštite resursa 

• procena ( assessment ). Procena je priprema za ostale tri komponente. Smatra se 
posebnom akcijom zato što je u vezi s pravilima, procedurama, pravnom i 
drugom regulativom, određivanjem budžeta i drugim upravljačkim dužnostima, i 
još je povezana s tehničkom procenom stanja zaštite. Greška u proceni bilo kog 
od ovih elemenata može naškoditi svim operacijama koje slede. 

• zaštita (protection ). Zaštita, tj. sprečavanje ili prevencija, podrazumeva primenu 
protivmera kako bi se smanjila mogućnost ugrožavanja sistema. Ukoliko zaštita 
zakaže, primenjuje se sledeći korak - otkrivanje. 

• otkrivanje ( detection ). Otkrivanje ili detekcija predstavlja proces identifikacije 
upada, tj. povrede sigurnosnih pravila ili incidenata koji se odnose na sigurnost. 
Neki autori definišu incident kao svaki „nezakonit, neovlašćen ili neprihvatljiv 
postupak koji je preduzet, a odnosi se na računarski sistem ili mrežu”. 

• odgovor (response). Odgovor ili reakcija predstavlja proces oporavka, tj. lečenja 
posledica upada. U aktivnosti reakcije spadaju postupci „zakrpi i nastavi”, ili 
„goni i sudi”. Ranije se na prvo mesto stavljalo oporavljanje fimkcionalnosti 
oštećenih resursa, kao što je korišćenje rezervnih kopija podataka za vraćanje 
sistema u stanje pre izvršenog napada. U novije vreme sve češće se koriste 
pravna sredstva (sudski proces protiv onoga ko ugrožava sigurnost), među koja 
spada prethodno prikupljanje dokaza metodama digitalne forenzike pomoću 
kojih se potkrepljuje tužba. 
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3 Platni sistemi 

Definicija plaćanja može se i pojednostaviti: plaćanje je prenos novčanih vrednosti. 
Pravna definicija platnog sistema bi mogla bi se formulisati na sledeći način: platni 
sistem je organizacija koja podržava prenos vrednosti u smislu ispunjenja novčanih 
obaveza. Platni sistem, u najširem smislu, predstavlja skup sistema za transfer novčanih 
sredstava koji olakšavaju cirkulaciju novca. Da bi platni sistem na zadovoljavajući način 
obavljao svoju ulogu, potrebno je da se novčana sredstva što kraće zadržavaju u 
kanalima platnog prometa. Pored toga, sistem treba da bude pouzdan, što prvenstveno 
znači bezbedno izvršavanje transakcija i postojanje kontinuiteta raspoloživosti prema 
korisnicima. Izvršavanje transakcija po ekonomski prihvatljivim cenama takođe je 
značajna karakteristika koja doprinosi kvalitetu platnog sistema. S obzirom na to da 
platni sistem utiče na brzinu ekonomskih tokova, troškove i likvidnost učesnika, kao i 
da predstavlja kanal za transmisiju mera monetarne politike, odnosno da njegovo 
neadekvatno funkcionisanje može da naruši poverenje javnosti u celokupni finansijski 
sistem - jasna je izrazita zainteresovanost centralne banke da obezbedi njegovo 
pouzdano i efikasno funkcionisanje [33]. 

Banka za međunarodna poravnanja [23] podrazumeva da je platni sistem skup 
instrumenata, učesnika, bankarskih procedura i infrastrukture koja omogućava vršenje 
funkcije. Platni instrumenti su standardizovana forma kojom se inicira plaćanje. 
Razlikuju se instrumenti kojima se iniciraju kreditni, operacije direktnog zaduženja, 
elektronske platne kartice, čekova i elektronskog novca. Raznovrsnost ponude platnih 
instrumenata i upotreba novijih i efikasnijih instrumenata kao što su elektronske kartice 
i elektronski novac određuje stepen razvoja platnog sistema. 

Uloga učesnika u platnim sistemima menja se u zavisnosti od stepena razvijenosti 
platnog sistema koji posmatramo i konkretnih rešenja koja su primenjena u njegovoj 
organizaciji. Najvažniji učesnik u platnim sistemima, a posebno ako su u pitanju zemlje 
u razvoju, jeste centralna banka koja ima ulogu i vlasnika i organizatora platnog 
sistema. Iz tih uloga proizilaze i ostale, kao što su donošenje radnih procedura, odluka i 
uputstava i kontrola sprovođenja donetih akata [147]. Centralna banka ostvaruje potpuni 
uvid i kontrolu nad svim elementima platnog sistema zemlje, a osim toga analizira i 
usklađenosti platnog sistema sa međunarodnim standardima. 

Najveća grupa učesnika u platnom sistemu jesu poslovne banke, kojima je platni promet 
tradicionalno deo portfolija usluga [137]. Radi poboljšanja konkurencije, sa ciljem da se 
postignu viši nivo kvaliteta i niže cene, u poslove platnog prometa uključuju se i 
štedionice, mreže, odnosno automatske klirinške kuće koje se bave prometom po 
osnovu platnih kartica i onlajn provajderi, kao što su Рау Pall i Cvbercash. Učesnici 
platnog prometa mogu biti trezori, koji u pojedinim državama imaju direktan pristup 
platnom sistemu, odnosno transakcije puštaju direktno, bez posrednika u sistem, kao i 
institucije koje vrše poravnanje u trgovini hartijama od vrednosti [109]. 

Značaj i uticaj poslova platnog prometa dugo je smatran jednostavnim i trivijalnim, 
čime je zanemarivana činjenica da platni sistemi predstavljaju kičmeni stub svake 
privrede. Stavovi se u poslednjih dvadeset godina menjaju i uviđa se da na nivo 
privrednog razvoja jedne zemlje utiče na nivo razvijenosti platnog sistema [110], a 
susrećemo i stavove da se platni sistem mora posmatrati kao ključna komponenta 
finansijskog tržišta zemlje [198]. 
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3.1 Osnovni pojmovi i defmiđje 

Banka za međunarodna poravnanja izdala je Objašnjenja termina korišćenih za platne 
sisteme i sisteme poravnanja [28], koja su prevedena i na srpski jezik i koji se nalazi na 
sajtu Narodne banke Bosne i Hercegovine [37]. Rečnik je napravljen tako da uglavnom 
definicijom termina objasni reč. U nastavku se nalazi skup pojmova sa definicijom koji 
se uobičajeno koriste prilikom definisanja elementa platnog sistema. 

Plaćanje je trasatov transfer monetarnog potraživanja na strani koja je prihvatljiva za 
trasanta. Karakteristično potraživanje dobija oblik novčanica ili saldo depozita kod 
finansijske institucije ili centralne banke. 

Platni sistem se sastoji od skupa instrumenata, bankarskih procedura i sistema 
međubankarskog transfera sredstava koji osigurava cirkulaciju novca. 

Kreditni transfer, platni nalog ili niz platnih naloga urađenih u svrhu stavljanja 
finansijskih sredstava na raspolaganje primaocu. I platni nalozi i finansijska sredstva 
opisana u tom smislu kreću se od banke platilaca/inicijatora do banke korisnika, moguće 
preko nekoliko drugih banaka posrednika i/ili vise od jednog kreditnog transfer sistema. 

Direktno zaduženje je ranije odobreno zaduženje na bankovnom računu [130] platioca 
inicirano od strane primaoca. 

Platni instrument je svaki instrument koji omogućava imaocu/korisniku transfer 
sredstava. 

Platna instrukcija ili nalog (platna poruka) za transfer sredstava (u obliku monetamog 
potraživanja od neke ugovorne strane) po nalogu korisnika. Nalog se može odnositi ili 
na potražni transfer ili na dugovni transfer. 

Klirinška kuća. Centralno mesto mehanizma za centralnu obradu preko kojeg se 
finansijske ustanove sporazumevaju da razmene naloge za plaćanje ili dmge finansijske 
obaveze (npr. vrednosne papire). Te institucije poravnavaju ono što su razmenile u 
određeno vreme na osnovu pravila i procedura klirinške kuće. U nekim slučajevima 
klirinška kuća može preuzeti značajnu ulogu dmge strane, finansijske odgovornosti ili 
odgovornosti upravljanja rizikom, za klirinški sistem. 

Kliring (obračun). Kliring je proces [139] transfera informacija i obračunavanje 
obaveza između dužnika i poverioca (banaka). Sastoji se od identifikacije, poravnanja i 
potvrđivanja. 

Poravnanje. Aktuelan transfer sredstava izmedju dve strane. 

Na slici 102. hijerarhijski su prikazani učesnici u platnim sistemima, od Retail učesnika 
u svojim platnim sistemima, preko IVholesale učesnika, koji imaju svoje platne sisteme, 
pa do platnog sistema centralne banke. Radi se o jednom veoma kompleksnom sistemu, 
a ta činjenica se može ilustrovati i brojem učesnika u svakodnevnom radu RTGS 
sistema centralne banke sa podređenim sistemima [129]. 

Platni instrument može biti definisan kao skup formi i procesa u cilju izmene 
vlasništva u smislu plaćanja. Platni instrument može biti definisan i kao alat za 
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inicijalizaciju transfera u smislu plaćanja. Instrumenti i načini njihovog korišćenja mogu 
se veoma razlikovati, sajasnim izuzetkom kod gotovog novca, gde je u svim zemljama 
sveta njegovo značenje i korišćenje identično. 

U definiciji Banke za međunarodna poravnanja gde se pod instrumentom plaćanja 
podrazumeva bilo koji instrument koji omogućava prenos sredstava. Na slici 6. 
prikazani su instrumenti plaćanja u Srbiji. Svi nalozi koje treba da se realizuju 
završavaju u RTGS sistemu Narodne banke Srbije ili kliring sistemu Narodne banke 
Srbije, u zavisnosti od visine iznosa sredstava iskazanog na nalogu. 

Elektronski platni instrument može biti definisan kao skup elektronskih fonni i 
elektronskih procesa u cilju izmene vlasništva u smislu plaćanja. Elektronsko plaćanje 
je transfer elektronskim sredstvima do korisnika korišćenjem elektronskog platnog 
instrumenta. Danas se koristi veoma širok spektar elektronskih instrumenata. Oni 
uključuju, na primer, direct debit, debitne kartice, kreditne kartice, Credit Transfers kao 
alate koje u sebi sadrži veoma raznorodne kumulativne skupove servisa i platnih portala 
sa različitim instrumentima plaćanja. 

Na slici 7. prikazan je jedan takav portal koji u sebi objedinjuje više elektronskih 
instrumenata plaćanja. Važno je napomenuti da finansijska institucija, na prikazanom 
primeru u pitanju banka, je sama dizajnira elektronski instrument u skladu sa svojom 
poslovnom politikom, definisanim profilom poslovanja, profilom svojih korisnika. 



Slika 6. Primer instrumenata za plaćanja: nalozi za uplatu, isplatu, prenos i naplatu 

Nacionalni platni sistem institucionalne i infrastrukturne elemente i procesa za iniciranje 
i prenos novčanih prava u skladu sa obavezama centralne banke i komercijalnih banaka. 
On obuhvata tržište kapitala i tržište vlasničkog kapitala (akcije). Izuzetno važno mesto 
zauzimaju procesi poravnanja hartija od vrednosti. Okvir postavljen na ovaj način može 
da predstavi celokupan platni sistem jedne zemlje - nacionalni platni sistem. 
Komponente, celine i tokovi mogu se videti na slici 8. Infrastruktura nacionalnog 
platnog sistema [33] sačinjena je od međusobno povezanih celina. Nacionalni platni 
sistemi razlikuju se u zavisnosti od veličine zemlje i njenog privrednog razvoja, ali 
ukoliko bismo izvršili generalizaciju, osnovni elementi su: institucionalna 
infrastruktura, sistem plaćanja velikih vrednosti, sistem(i) plaćanja malih vrednosti i 
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sistem(i) za kliring i saldiranje hartija od vrednosti. 



I Prenos 




23.09.2007 I 

Prenos sa računa: 

| SNBTekuci 

d 



Stanje: 

662,10 




Raspoloživa sredstva za gotovinu: 

562,10 




Dozvoljena pozajmica: 

0.00 

do 



Nedospele obaveze: 

100,00 

[ Prlkažl 

1 


Nerealizovani čekovi: 

0 




Poslednja uplata: 

1.200.00 

02.03.2007 



Poslednja isplata: 

100,00 

31.08.2007 



Prenos na račun: 

Iznos: 

1 

□Ш 

| Izvrll 

| Izaberite račun... 

d 





Slika 7. Prikaz skupa servisa i portala elektronskih instrumenata plaćanja 



Slika 8. Nacionalni platni sistem 
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Svi nacionalni platni sistemi spadaju u kategoriju sistemski značajnih platnih sistema 
(,Systematicly Important Pavment Svstem - SIPS ). U razvijenim privredama osim 
centralnog platnog sistema funkcionišu i drugi platni sistemi, ali oni ne moraju imati 
sistemski značaj. Sistemski značajne platne sisteme karakteriše veliki obim transakcija 
(po broju i veličini), čime bi otkaz ili nepravilnost u njihovom radu ugrozio 
funkcionisanje privrede u celini. U Srbiji se pravi razlika „između sistemski značajnih i 
značajnih platnih sistema, pri čemu je sistemski značajan platni sistem onaj čiji 
poremećaji u radu ili u radu njegovih učesnika mogu izazvati ozbiljne poremećaje u 
finansijskom sistemu, a kod značajnog platnog sistema oni se ne mogu izazvati, ali se 
može izazvati nepoverenje učesnika i njihovih klijenata u te sisteme“. Sistemski 
značajan platni sistem mora da ima mehanizme za upravljanje sistemskim rizicima, koji 
bi sprečili „domino cfckat“, odnosno lančanu reakciju u slučaju otkaza jedne banke ili 
više banaka u sistemu [33]. 

3.1.1 Sistemi procesorskih kuća 

Klasifikacija platnih sistema, slika 9., može se izvršiti na osnovu načina plaćanja, 
mesta plaćanja, veličine obračuna, načina obračuna i vremena obračuna [33]. 
Klasifikacija rizika sistema za poravnanje klirinških kuća prikazana je u tabeli 1. 

Klasifikacija platnih sistema na osnovu načina plaćanja. Klasifikacija platnih 
sistema prema načinima plaćanja vrši se u odnosu na prisustvo ili odsustvo posrednika 
u platnom prometu. Razlikuju se dve vrste aranžmana. Bilateralni korespondentski 
platni aranžmani predstavljaju najjednostavniji način povezivanja dve banke u platnom 
prometu. Banke su međusobno povezane nostro/loro računima i nije potrebno 
uključivanje posrednika. Platni aranžmani uz prisustvo agenta poravnanja 
podrazumevaju da se saldiranje između dve strane ne obavlja direktno, već da je 
uključen posrednik. Automatske klirinške kuće ( Automated Clearing Houses - ACH) 
najznačajniji su posrednici u savremenim poslovima platnog prometa i omogućavaju 
multilateralne platne aranžmane. One su jedna od prvih fonni računarski podržane veze 
između banaka koja se oslanja na mrežnu tehnologiju i predstavlja preteču 
elektronskog transfera novca. 



Slika 9. Pregled sistema za razmenu vrednosti 
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Klasifikacija platnih sistema prema mestu plaćanja. Platni sistemi se, prema mestu 
plaćanja, odnosno mestu na kome se nalaze lica (institucije) koje u njima učestvuju, 
dele na unutrašnji (nacionalni) i međunarodni (prekogranični) platni promet. 

Klasifikacija platnih sistema prema veličini transakcija. Platni sistemi se, prema 
kriterijumu veličine transakcije, mogu podeliti na sisteme koji vrše transfer transakcija 
velikih vrednosti ( large -value funds transfer ili large-value transfer systems ) i sisteme 
koji vrše transfer transakcija malih vrednosti ( retail funds transfer ili small-value 
transfer systems). Platni sistemi velikih vrednosti dominantno se odnose na (relativno) 
mali broj plaćanja velikih vrednosti, koji su vremenski veoma osetljivi. U sistemima 
plaćanja malih vrednosti, u kojima se procesira veliki broj transakcija plaćanja, obično 
male vrednosti u formi čekova, transfera odobrenja, direktnih zaduženja i plaćanja 
platnim karticama. Ti sistemi ne moraju biti od sistemske važnosti, ali su od značaja za 
poverenje javnosti u mehanizme i način obavljanja transakcija plaćanja. 

Klasifikaeija platnih sistema prema načinu obračuna. Nakon iniciranja procesa 
plaćanja, banke primaju platne instrukcije, nakon čega nastupa faza saldiranja 
(poravnanja) između banaka učesnica u procesu. Razlikuju se dva modaliteta 
saldiranja, prema kojima se vrši klasifikacija platnih sistema. To su neto obračun i 
bruto obračun. 

Neto obračun ( net settlement ili netting) ili odloženi neto obračun ( differed net 
settlement - DNS) Multilateralne neto operacije podrazumevaju prikupljanje 
instrukcija plaćanja od svih učesnika, da bi se nakon kliringa knjižile samo razlike 
(salda). Drugim rečima, netting sistemi predstavljaju operativnu proceduru saldiranja 
između komercijalnih banaka, pri kojoj se potraživanja i obaveze svake pojedinačne 
banke potiru (kompenzuju) u toku radnog dana (najčešće više puta), a na kraju radnog 
dana banke moraju da pokriju samo svoja negativna salda. Sistemom za neto obračun 
najčešće se procesira veliki broj malih plaćanja, tako da je moguće grupisanje, 
sortiranje i izračunavanje neto pozicije za svaku banku pojedinačno. 

Bruto obračun ( gross settlement) podrazumeva da se obračun svih individualnih 
plaćanja vrši pojedinačno, jedan po jedan. U modelu bruto obračuna razlikuju se tri 
modela: model koji dozvoljava prekoračenja, model u kome prekoračenja nisu 
predviđena, model redova čekanja. Bruto obračun podrazumeva da svaki nalog bude 
pojedinačno obrađen i uknjižen, što čini ovu vrstu obračuna znatno skupljom od neto 
obračuna. Osim toga, banke moraju da imaju veći iznos sredstava koji će im omogućiti 
likvidnost tokom celog dana. Opravdanje za široku upotrebu ovog modela proizilazi iz 
redukovanog rizika jer je problem sistemskih rizika mnogo izraženiji kod 
multilateralnog neto obračuna. 

Klasifikacija platnih sistema prema vremenu obračuna. Klasifikacija platnih 
sistema može se izvršiti i prema vremenu, odnosno hitnosti obračuna transakcija. U 
tom smislu razlikujemo sisteme koji vrše obračun u realnom vremenu, tako da se sve 
transakcije obrađuju čim stignu u sistem i sisteme sa odloženim obračunom, u kome se 
transakcije obrađuju i saldiraju u unapred definisanim vremenskim intervalima ili na 
kraju radnog dana. 
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rbr 

Naziv rizika 

Opis rizika 

1 . 

Rizik 

poravnanja 

Opšti termin koji se koristi da se označi rizik da se poravnanje u sistemu transfera neće 
desiti kako se očekivalo. Ovaj rizik može uključivati i kreditni i likvidni rizik 

2. 

Kreditni 

rizik 

Rizik da ugovoma strana neće poravnati obavezu, u punoj vrednosti, kada je dospela ili u 
bilo koje vreme kasnije. U sistemu razmene za vrednost, rizik je obično definisan tako da 
uključuje troškove rizika zamene i glavni rizik. 

3. 

Rizik 

likvidnosti 

Rizik da ugovorna strana (ili učesnik u sistemu poravnanja) neće poravnati obavezu u punoj 
vrednosti u vreme dospeća. Rizik likvidnosti ne uključuje činjenicu da je ugovoma strana ili 
učesnik nesolventan, pošto oni mogu biti u stanju da poravnaju tražene dugovne obaveze u 
nekom neodređenom periodu, kasnije. 

4. 

Operativni 

rizik 

Rizik ljudske greške ili kvara neke komponente hardvera ili komunikacijskog sistema koja 
je ključna za poravnanje. 

5. 

Sistemski 

rizik 

Rizik da će propust ispunjenja obaveza koje se od njega traže, jednog od učesnika u sistemu 
transfera ili uopšteno na fmansijskim tržištima, prouzrokovati da ostali učesnici ili 
fmansijske institucije ne budu u mogućnosti ispuniti svoje obaveze (uključujući poravnanje 
obaveza u sistemu transfera) o dospeću. Taj propust može prouzrokovati značajnu likvidnost 
ili kreditne probleme i kao rezultat toga mogu biti pretnja stabilnosti finansijskih tržišta. 


Tabela 1. Rizici kod sistema za poravnanje 


3.1.2 Platni sistemi banaka i drugih finansijskih organizacija 

Kao primer platnog sistema banke u nastavku će biti opisana Assecco-ov a softverska 
rešenja koja su u širokoj upotrebi u domaćim bankama [12]. 


Assecco je kompanija za razvoj softvera, specijalizovana za bankarska softverska 
rešenja. Osnovana je 1994. godine i vodeći je snabdevač bankarskog softvera u Srbiji, 
Crnoj Gori, Makedoniji i Bosni i Hercegovini. Razvila je softversko rešenje BI - 
Interaktivni transakcioni sistem koji omogućava dvadesetčetvoročasovni rad banke bez 
end-of-day/close-of-business prekida, čija je arhitektura prikazana na slici 10. 
Administracija sistema zajednička je centralizovana i za sve podsisteme. Na podsistem 
jezgra i administracije dodaju se ostali moduli BI sistema. Parametrizacija sistema je 
organizovana preko mehanizma bankarskog stabla koji obuhvata skup svih poslova koji 
se rade u banci. 


Application tier: 

Orade Intemet Apphcation Server 9i Enterpnse Edition: 
Oracle HTTP Server. Forms server. Reports server 


Database tier: 

DB: Oracle Server Standard/ 


Jm I - Огкк Datab»w 



Тмг II - ApplcaOor urvvt 


Appfcation S««y«r 1 


Applicsoon Sww 2 







Presentation tier: 

MS Internet Explorer. Netscape Navigator or Mozila Firefox 
Oracle Java Virtual Machine (Jlnitiator) 


Sporv Applcatior Server 


Slika 10. Troslojna arhitektura Antegra BI sistema [12] 
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Nacionalni platni promet. Podsistem za podršku nacionalnog platnog prometa 
obezbeđuje odgovarajuće tehničko okruženje, u okviru postojeće organizacione šeme 
banke, neophodno za obavljanje poslova službe platnog prometa u banci. Kao deo 
integrisnog Antegrinog sistema BI, ovaj podsistem ima čvrste veze sa svim ostalim BI 
podsistemima i potrebnim eksternim sistemima, slika 11, bez obzira na to da li on 
koristi njihove usluge, bilo tako što oni koriste njegove usluge za obavljanje plaćanja. 
Podsistem u potpunosti automatizuje razmenu podataka sa Klirinškom kućom i 
Centralnom bankom (STP - Straight Through Processing ). 


Centralna Banka 

¥4 



SWIFT 






E-banking sistemi 




Procesori kartlca 

• SAGA 

• HALCOM 

• РЕХ1М 


Bl 

sistem 


• Mellon 

• Arius - Europlanet 

• Transacty 






Corebanking sistemi 

• MIDAS 

• GLOBUS 




• ING banka 

• DELTA Slngular 


Slika 11. Veza Antegra BI sistema sa ekstemim sistemima [12] 

Organizacija platnog prometa. Poslovi platnog prometa obavljaju se u Sektom 
platnog prometa kome pripadaju: služba za praćenje disponibiliteta banke, obračunski 
centar banke, obradna mesta banke, prijemna mesta banke. Podsistem je koncipiran da 
može podržati dve vrste organizacionih stmktura: centralizovanu, u kojoj sve filijale 
fu nk cionišu kao prijemna mesta i postoji samo jedno obradno mesto, ili 
decentralizovanu, koju karaketriše visok stepen samostalnosti filijala koje su 
koncipirane kao obradna mesta. Vrste platnog prometa, u odnosu na uspostavljenu 
organizacionu stmktum, jesu: intemi platni promet filijala, intemi platni promet u banci 
i ekstemi platni promet između banaka. Bez obzira na vrstu platnog prometa, obrada 
naloga se vrši tako što se nalozi sa prijemnog mesta šalju na odgovarajuće obradno 
mesto. Posle uspešno obavljene autorizacije nalog se realizuje u intemom platnom 
prometu ili se šalje na realizaciju u eksterni platni promet. Nalozi se izvršavaju po 
redosledu koji definišu prioritet naloga i vreme prijema. Sistem vodi potpunu evidenciju 
o prilivima i odlivima sredstava banke. Na disponibilitetu se prate stanja ekstemih 
računa banke: žiro računa, računa rezervi, računa pozicija u bruto (RTGS - Real Time 
Gross Sistem ) i neto ( Giro Clearing) obračunu, računa poslatih i primljenih naloga. 

Transakcije u platnom prometu. Program za unos naloga za plaćanje, u osnovnom 
režimu rada, optimizovan je tako da omogući unos proizvoljnog naloga za plaćanje. Za 
specijalne vrste naloga za plaćanje, u cilju ubrzanja rada šalterskih radnika, postoje 
posebni režimi rada istog programa, u koje se lako ulazi. Specijalne vrste naloga su: 
gmpni nalozi, šabloni za tipske transakcije, prikupljanje sredstava i plaćanje 
komunalnim službama sa dostavljanjem specifikacija za rasknjižavanje u papirnom i 
elektronskom obliku. 

Platne kartice ( BiCard ). Ovaj modul obavlja poslove sa karticama koji se tiču back 
office funkcionalnosti (naplata potraživanja nastalih korišćenjem kartice) i rada na 
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šalteru. Pored ovoga on, u cilju postizanja jedinstvene tačke odobravanja svih 
transakcija i zaduženja računa klijenata kod banke, održava onlajn vezu sa 
komutacionim čvorištem transakcija po karticama. BiCard omogućava da se u okviru 
istog sistema integrišu svi standardni kartični proizvodi koje banka ima za cilj da izdaje. 
U okviru podsistema podržane su funkcije odloženog plaćanja i plaćanja na rate, koje su 
bile karakteristične za čekove po tekućim računima. Ova funkcionalnost bankama daje 
mogućnost da, sa platnim karticama, korisnicima pruže usluge slične onima koje su 
imali prilikom korišćenja čekova. 

Kreditne kartice. Kreditne kartice predstavljaju specifičnu grupu platnih kartica koja 
funkcioniše po principima obnavljajućih kreditnih limita. Kreditne kartice se dele na 
dve osnovne grupe Charge i Revolving. Za Charge kartice karakteristično je da sredstva 
potrošena u toku obračunskog perioda korisnik mora da uplati u celini u zadatom 
periodu. Kod Revolving kartica korisnik mora da uplati samo deo od ukupno potrošenih 
sredstava. Pored standardnih funkcionalnosti koje prate rad svih platnih kartica kao što 
su: prikupljanje zahteva, card managment, obrada i knjiženje transakcija i Onlajn 
autorizacije, kroz ovaj podsistem su dodate i nove funkcionalnosti kao što su: skoring, 
obračun potrošnje i formiranje obaveza korisnika, specifičan način obračuna kamate, 
praćenje uplata, praćenje kašnjenja sa uplatama korisnika i formiranje opomena. 

Veza sa novim procesorom. Deo poslovanja vezan za platne kartice kao što su 
upravljanje ATM i POS terminalima, personalizacija kartica, stand-in autorizacija i 
obezbeđivanje intefejsa prema kartičnim sistemima VISA, Master itd. za banke uslužno 
rade specijalizovane ustanove koje jednim imenom nazivamo procesori. Procesori sa 
kojima su uspostavljeni i online i offline način rada jesu: Mellon, Arius - Europlanet, 
Transactv, ING Banka, Chip card, Delat Singular. 

mBanking obaveštavanje. mBanking ( Mobile Banking ) modul generiše poruke o 
događajima na računima i karticama unutar Core banking sistema radi obaveštavanja 
komitenata o tim događajima u realnom vremenu. Svaka realizacija transakcije može da 
generiše odgovarajuću mBanking poruku, u zavisnosti od toga da li postoji 
odgovarajuće ovlašćenje za generisanje poruke ili ne. Generisane poruke predaju se 
ekstemim ili internim sistemima za obaveštavanje koji zatim obavljaju distribuciju 
poruka komitentima, koristeći raznovrsne komunikacione kanale. Generisanje velikog 
broja poruka može da zahteva značajne resurse sistema, ali zahvaljujući paralelnom 
procesiranju, mBanking minimalno usporava Antegrin core banking sistem. 

Web Paket. WebPaket je modul kojim se omogućava da se putem veb kanala (ekstemi 
eBanking sistem) univerzalnim zahtevom aplicira ili za kredit ili za kreditnu karticu. 
Zahtevi za ovaj proizvod se predaju, tj. unose kod prodavca. Trgovci putem veb 
aplikacije ekstemog eBanking sistema unose zahtev i dokumentaciju vezanu za zahtev 
koju prosleđuju Core sistemu gde se dalje vrši preuzimanje izveštaja iz kreditnog biroa, 
obavlja proces Scoring- a, verifikacije podataka i dokumentacije i donosi odluka o 
odobravanju, tj. neodobravanju zahteva. Nakon pozitivnog rešavanja zahteva (odobren 
zahtev), vrši se zaduživanje komitenta za iznos kupovine, dok se sredstva prebacuju na 
privremenu partiju trgovca. Tek po pristizanju originalne dokumentacije u vezi 
proizvoda koji se želeo finansirati kreditom ili kreditnom karticom, sredstva se sa 
privremene partije trgovcaprebacuju na stvamu partiju trgovca. 


Slobodan Babić \ Fakidtet organizacionih nauka 


49 



Doktorska disertacija: Model interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama 


Sepa Direct Debit module. Za banke u Srbiji u skladu sa uputstvima i odlukama 
Udruženja banaka Srbije i Narodne banke Srbije, a u saradnji sa partnerskim firmama 
Рехпп i Omnilogika iz Beograda, razvijen proizvod namenjen bankama pod imenom 
SEPA Direct Debit. Ovaj softverski modul omogućava banci da učestvuje u SEPA 
Direct Debit kliringu u Srbiji. Antegrino rešenje integriše se sa bankarskim sistemom u 
banci. Aplikacija komunicira sa jezgrom bankarskog softvera koji banka već koristi, 
preko jasno defi nisanih servisa. 

3.1.3 Multikanalni sistemi za plaćanja pravnih i fizičkih lica 

Kao primer multikanalnog sistema za plaćanje u nastavku biti će opisana Halcomova 
softverska rešenja, koja su u širokoj upotrebi u domaćim bankama [176]. Sistem je 
namenjen i pravnim i fizičkim licima. 

Halcomova softverska rešenja u upotrebi su u iO različitih monetarnih sistema 
(Slovenija, ВШ, Srbija, Crna Gora, Kosovo, Nemačka, Albanija, iran, Katar i Maroko), 
u 72 banke, četiri centralne banke i klirinške kuće i kod preko 141.000 zadovoljnih 
korisnika. Do sada je u okviru Halcom platnih sistema obrađeno preko 529.000.000 
platnih naloga. Halcomove certifikacione agencije izdale su preko 190.000 pametnih 
kartica sa digitalnim sertifikatima. 

Hal E-bank jc namenjen preduzećima koja imaju jedno ili više radnih mesta za rad sa 
elektronskom bankom. Svaka ovlašćena zaposlena osoba prilikom otvaranja programa 
prijavljuje se u sistem pomoću svoje personalizovane pametne kartice. Na osnovu 
ovlašćenja dodeljenih od strane preduzeća za određeni račun vlasnik pametne kartice 
dobija dozvolu za rad samo sa onim funkcijama za koje je ovlašćen. Povezivanje sa 
bankom vrši se prema izboru: preko interneta, pozivne linije ili iznajmljene linije. 

Hal E-banki SMS omogućava: obaveštenja o promenama na računima, informacije o 
stanju ili realizovanim transakcijama, plaćanja na predefinisane račune. 

Hal E-bank/International Cash Management pravnom licu omogućava upravljanje 
računima sa istim rešenjem elektronske banke na računima u bankama u inostranstvu 
preko usluga domaće banke. Banka rešenjem International Cash Management pruža 
klijentima globalno poslovanje i dodatne usluge boljeg upravljanja sa sredstvima na 
svim svojim računima. 

Hal M-Bank je jednostavno, brzo i sigurno rešenje za elektronsko bankarstvo preko 
mobilnog telefona. Hal M-Bank omogućava upotrebu usluga koje se najviše koriste kod 
elektronske bankc* neposredno preko mobilnog telefona. 

Hal M-Payments je rešenje za jednostavno i sigumo mobilno plaćanje koje koristi 
digitalni potpis i funkcioniše na običnim mobilnim telefonima 

Hal E-Invoices rešenje za distribuciju e-faktura kao siguran komunikacijski kanal 
upotrebljava postojeće rešenje za elektronsko bankarstvo i zato omogućava automatsko 
plaćanje i knjiženje, kao i jednostavni vremenski pečat i dugoročno arhiviranje e- 
faktura. Osnovna zamisao Halcomovog rešenja za distribuciju e-faktura jeste da se 
elektronska faktura iz informacionog sistema prodavaca preko elektronske banke 
prenese u infonnacioni sistem kupca. U kupčevoj e-banci se iz podataka e-faktura 
jednostavno kreiraju platni nalozi, koje kupac zatim mora elektronski da potpiše. Kod 
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П rm i koje koriste naprednije sisteme za podršku poslovnih procesa, e-faktura se 
jednostavno, kako na kupčevoj tako i na prodavčevoj strani, automatski knjiži u 
njihovim pozadinskim obradama (ERP). Najznačajnije prednosti Hal E-Invoices za 
pravne osobe jesu: distribucija podataka putem sigurnog i stabilnog komunikacijskog 
kanala (koristi rešenje za elektronsku banku), automatsko plaćanje i knjiženje, rešenje je 
nezavisno od fonnata podataka pošiljaoca i primaoca e-faktura, kao i od oblika e- 
faktura, omogućava jednostavni elektronski pečat i dugoročno arhiviranje e-faktura 
zajedno sa drugim Halcomovim rešenjima. Rešenje Hal E-Invoices omogućava 
distribuciju e-faktura takođe i domaćinstvima i pojedincima. Putem veb portala e- 
fakture se mogu distribuirati i pojedincima koji ne koriste elektronsku banku. Potrošač 
(kupac) koji prihvati (ugovori) primanje e-faktura može pristupiti svom mailbox- u, na 
koji mu je upućena e-faktura sa digitalnim certifikatom. 

Hal E-Forms je koncept informatičkih rešenja koji banci omogućava dodavanje novih 
e-obrazaca za željene e-usluge bez posredovanja programerskih kuća. Banka dobija alat 
sa kojim sama napravi e-obrazac (na osnovu postojećih dokumenata Word, Adobe PDF) 
i distribuira ga korisnicima. Korisnik takve obrazsce primi kroz kanala elektronske 
banke, popuni, digitalno potpiše i pošalje nazad do banke. 

Hal E-Archive je efikasan način za elektronsko arhiviranje digitalno potpisanih i 
vremenski overenih e-dokumenata, kao i ostalih dokumenata u elektronskom obliku radi 
revizijskog praćenja i zakonske potrebe čuvanja platnih naloga. Među najvažnijim 
prednostima je jednostavna upotreba, nemogućnost da dođe do gubitka arhiviranog 
dokumenta, kao i najviša stopa sigumosti i zaštite podataka. 

Hal E-Clearing jc sistem međubankarskih sravnjenja plaćanja malih vrednosti kao što 
su kreditna plaćanja, neposredna terećenja, sravnjenje čekova i POS transakcija. Pri 
tome je moguće bilateralno ili multilateralno sravnjivanje pojedinih vrsta plaćanja ili 
svih plaćanja u celosti u sistemima za međubankarska bilateralna ili multilateralna 
plaćanja malih vrednosti. 

3.2 Standardi platnih sistema 

Osnovne inicijative na finansijskom tržištu po pitanju standardizacije koje globalne 
institucije sprovode prikazani su u tabeli 2. Ukoliko finansijske organizacije koje se 
bave platnim sistemima žele da se na savremen način bave finansijskim servisima i da 
nude savremene finansijske proizvode jasno je da je neophodno i uključivanje 
finansijske organizacije u rad navedenih institucija. 


rbr 

Naziv inicijative 

Opis inicijative 

1 . 

Inicijative u domenu standarda i 
primene 

Inicijative koje se odnose na aktivnosti kojima je osnovni smer delovanja 
razvoj i implementacija standarda i prakse na tržištu 

2. 

Infrastruktume inicijative 

Inicijative povezane sa razvojem tržišne infrastmkture koja ima primenu 
u međunarodnom tržištu 

3. 

Inicijative na polju rešenja 

Gmpa inicijativa za razvoj specifičnog proizvoda ili servisa 

4. 

Inicijative u domenu regulacija 

Regulacije koje imaju uticaj u domenu globalnih plaćanja 


Tabela 2. Osnovne inicijative na globalnom tržištu plaćanja [48] 
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rbr 

Naziv 

Opis 

Link 

1 . 

COGEPS 

razvija evropsku strategiju u domenu plaćanja 

www.abe.0r2 

2. 

EBA 

zadužena za razvoj platne infrastrukture evropske 
zajednice 

www.abe.0r2 

3. 

EC 

zadužen za razvoj jedinstvenog evropskog tržišta 

www.eurona.eu.int 

4. 

ECB 

Banka centralnih banaka Evropske unije 

www.ecb.int 

5. 

ECBS 

odgovoma za identifikaciju i promociju standarda 
u skladu sa potrebama evropske bankarske 
industrije 

www.ecbs.0r2 

6. 

EPC 

zadatak je da kreira arhitektum, instmmente i 
procese za Single Euro Payment Area (SEPA) 

www.eur0Deannavmentc0ncil.0r2 

7. 

Eurogiro 

uloga je uvećanje kooperacije izmeđe žiro i banaka 
pošta u domenu plaćanja 

www.eurosiro.com 

8. 

FED 

vodeća od 12 US FED banaka u mkovođenju 
aktivnostima iz oblasti fmansijskih servisa i 
odgovarajuće podrške 

www.frbservices.0r2 

9. 

G -30 

osnovana od strane Međunarodnog monetamog 
fonda, BIS, ECB, centralnih banaka, vodećih 
fmansijskih institucija i univerziteta da utvrdi 
moguću praksu i polise 

WWW. 2 rOUD 30 .Or 2 

10. 

GPC 

osnovana od strane devet vodećih bankarskih gmpa 
u cilju smanjenja troškova i izgradnje efikasnijeg 
fmansijskog tržišta za sve učesnike 


11. 

Identrus 

obezbeđuje fmansijske institucije - članice sa 
potrebnim standardima za utvrđivanje digitalne 
autentifikacije 

www.identms.com 

12. 

IFX 

kreira XML standarde za razmenu pomka, 
fokusirana na modebranju end-to-end poslovne 
transakcije uključujući i Retail bankarske potrebe 

www.ifxf0rum.0r2 

13. 

ISO 

mreža nacionalnih institucija za standardizaciju 

www.iso.ch 

www.isol 5022 .or 2 

www.iso20022.or2 

14. 

TC 68 

pokriva aktivnosti iz oblasti bankarstva, hartija od 
vrednosti i dmgih fmansijskih servisa, pridmžena 
SWIFT organizacija 


15. 

OAG 

promoviše metodologiju baziranu na poslovnim 
procesima i XML sintaksi 

www.0DenaDDlicati0ns.0r2 

16. 

OASIS 

globalni konzorcijum koji vodi razvoj, 

konvergenciju među standardima i adaptaciju 
standarda u domenu elektronskog poslovanja za 
bezbednost, veb-servise, XML, poslovne 

transakcije, elektronsko izdavaštvo i 

transparentnost između različitih tržišta 

www.oasis.ors 

18. 

SWIFT 

neprofitna organizacija koja obezbeđuje servise i 
softver za razmenu pomka između preko 7000 
fmansijskih institucija u preko 200 zemalja 

www.swift.com 

19. 

TWIST 

inicijativa predvođena sa Rozal Dutch/Shell da 
defmiše XML standarde za korporativne korisnike 

www.twiststandards.0r2 


Tabela 3. Važnije organizacije sa globalnim uticajem u finansijskoj industriji 

U tabeli 3. prikazane su važnije globalne organizacije koje imaju presudan uticaj u 
formiranju finansijskog tržišta, posebno u domenu platnog prometa. Poražavajuća 
činjenica je neučestvovanje srpskih predstavnika u tim institucijama. Vodeća globalna 
uloga pojedinih finansijskih organizacija inicijalizovana je upravo mogućnošću 
stvaranja adekvatnog okruženja za poslovanje. Ukoliko srpske finansijske institucije 
žele da budu podjednako razvijene kao inostrane, moraju u vrlo kratkom vremenskom 
periodu da se uključe u rad tih institucija. Inače će inostrane finansijske institucije 
zauzeti vodeću ulogu u formiranju i našeg tržišta i na taj način dobiti tržišnu utakmicu. 
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Razvoj EDI standarda započeto je sedamdesetih godina prošlog veka i to nezavisno u 
Severnoj Americi i Evropi. Započeta standardizacija elektronske razmene podataka se 
nastavlja i danas, a najzastupljeniji standardi danas su EDIFACT, ISO15022 (sa SWIFT 
MT podstandardom) i najsavremeniji IS020022 standard koji će biti opisan u narednim 
poglavljima. 

3.2.1 EDIFACT standard 

Danas je informaciona tehnologija osnova savremene i cfikasnc ekonomije i poslovnog 
komuniciranja u međunarodnim razmerama, a standardi su preduslov njenog bržeg 
razvoja i primene [180]. U prethodnih nekoliko godina veliki značaj dobile su aktivnosti 
međunarodne standardizacije na području elektronske razmene podataka (EDI) i 
donošenje skupa standarda pod zajedničkim imenom EDIFACT sa ciljem da se olakšaju 
i ubrzaju tokovi roba i usluga na međunarodnom planu. Veoma ozbiljne pripreme za 
primenu standarda EDIFACT (Electronic Data Interchange For Administrations 
Commerce and Transport ) u raznim regionima, zemljama, asocijacijama i finnama, 
praktično na svim kontinentima prinudile su zemlje, organizacije i finne koje žele da 
zadrže svoje mesto na svetskim tržištima da vrlo brzo prihvate EDI tehnologiju po 
EDIFACT standardima [55]. 

S tehničke strane gledišta EDI (Elektronska razmena podataka) je razmena 
strukturiranih komercijalnih podataka između računara zasebnih firmi, izvršena bez 
manuelne intervencije, elektronskim putem, posredstvom standardizovanih poruka koje 
zamenjuju tradicionalne papime komercijalne dokumente. Ovakva odrednica sadrži više 
bitnih elemenata, bez čijeg zadovoljenja ne može biti reči o elektronskoj razmeni 
podataka. EDI je razmena podataka. Razmena podrazumeva dvosmemi prenos pomka. 
EDI je razmena strukturisanih komercijalnih podataka. Sem komercijalne prirode, 
pomke moraju imati format koji omogućava mašinsku obradu. EDI je razmena podataka 
između računara zasebnih firmi. Pojam zasebnih firmi ne treba posmatrati sa aspekta 
pravnih subjekata, već sa stanovišta da svaki deo iste finne, opremljen računarom, teži 
optimizaciji svog dela posla, pa EDI može da služi za razmenu podataka, kako sa 
drugim pravnim subjektima tako i sa drugim delovima iste finne, sa kojima je u 
poslovnim interakcijama. EDI je razmena pomka između računara bez manuelne 
intervencije. EDI je razmena podataka između aplikacija, a ne između ljudi, kao što je 
to slučaj kod elektronske pošte. EDI je razmena elektronskim putem. Razmena 
magnetnih medija, čak kada bi oni sadržali stmkturisane komercijalne podatke, 
očigledno ne predstavlja EDI. EDI je razmena posredstvom standardizovanih pomka i 
podrazumeva postojanje usvojenih standarda za stmkturisane pomke. EDI je razmena 
pomka koje zamenjuju tradicionalne komercijalne papirne dokumente. 

Odluka poslovnog mkovodstva o primeni elektronske razmene podataka mora da sadrži 
mnogo više od želje da se razmena podataka između računara vrši elektronskim putem, 
u skladu sa usvojenim standardima. Ta odluka, pre svega, mora da sadrži neke 
poslovne, ekonomski valorizovane ciljeve. U širokoj lepezi ciljeva za koje se firme, 
danas u sve većoj meri multinacionalno poslovno orijentisane, opredeljuju za uvođenje 
elektronske razmene podataka najčešće se navode: 

• smanjenje troškova papirne dokumentacije (papira, osoblja, vremena); 

• smanjenje obima ljudskih grešaka u obradi podataka; 

• brža i bolja informisanost i dostava infonnacija; 

• efikasnije upravljanje novčanim sredstvima; 
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• mogućnost poboljšanog upravljanja zalihama; 

• poboljšano upravljanje transportom i distribucijom; 

• poj ednostavlj enj e i ubrzanj e carinskih procedura; 

• povećanje produktivnosti; 

• prevazilaženje jezičkih barijera i problema različitih vremenskih zona. 

Sa standardima za EDI počelo se sedamdesetih godina i to nezavisno u Severnoj 
Americi i Evropi. Ovi standardi su donošeni na svim nivoima: na nivou preduzeća, 
država, regiona, delatnosti, samo ne na međunarodnom nivou. Tako su prvi ANSI Х.12 
standardi doneti sredinom osamdesetih godina i primenjivali su se u Severnoj Americi. 
Istovremeno su se u Evropi primenjivali GTDI standardi ( Guidelines Trade Data 
Interchange) usvojeni od strane UN ECE. Inicijativa za izradu međunarodnih standarda, 
baziranih na razvoju i iskustvima primene ANSI Х.12 i UNIECE GTDI standarda 
potekla je 1985. godine i urodila plodom već 1987. godine usvajanjem standarda pod 
zajedničkim akronimom UN/EDIFACT. Prema definiciji usvojenoj na 31. sednici 
UN/ECE/WP.4, u martu 1990. godine, UN/EDIFACT su pravila Ujedinjenih nacija za 
elektronsku razmenu podataka u oblasti administracije, trgovine i transporta. Ona 
obuhvataju skup međunarodnih standarda, kataloga i uputstava za EDI, naročito onih 
koja se odnose na trgovanje robom i uslugama između nezavisnih, automatizovanih 
infonnacionih sistema. 

Skup UN/EDIFACT standard obuhvata: 

• poruke UNSM ( United Nations Standard Messages ); 

• kataloge elemenata iz kojih se grade ove poruke (segmenata, složenih 
elemenata podataka i elemenata podataka); 

• kodne liste elemenata podataka koji se prikazuju u šifriranom obliku; 

• uputstva i pravila za razvoj i implementaciju ovih standarda. 

Rad na UN/EDIFACT standardima odvija se u saradnji sa ISO organizacijom i sa 
odborima za EDICAFT širom sveta i po modelu grupa za razvoj poruka u finansijskoj 
industriji, trgovini, carini, statistici, zdravstvu, turizmu i javnim službama. Evropa je 
odigrala ključnu ulogu u izradi standarda za elektronske ekvivalente klasičnih 
dokumenata preuzevši koordinaciju izrade EDIFACT poruka u okviru WEEB ( Western 
European EDIFACT Board ). Razvijene su Standardne poruke Ujedinjenih nacija 
(United Nations Standard Message - UNSM), poruke koje pokrivaju sve aspekte 
administrativnih, trgovinskih i transportnih transakcija. Glavni nosioci međunarodne 
standardizacije za EDI su: UN/ECE, Međunarodna organizacija za standardizaciju ISO i 
Međunarodna telekomunikaciona unija (ITU - International Telecommtmication Union). 
U bankarskom poslovanju standardizacija, u kojoj EDI zauzima značajno mesto, 
predstavlja važan preduslov razvoja jedinstvenog finansijskog informacionog sistema. 
Standardizacija treba da: 

• identifikuje postojeće standarde: nacionalne, međunarodne, evropske, granske; 

• identifikuje donosioce standarda, kao i metodologiju izrade; 

• identifikuje standarde za projektovanje informacionog sistema (softverski 
inženjering, razmenu podataka, zaštitu, protokole); 

• utvrdi prioritete preuzimanja međunarodnih standarda,pravnu regulativu; 

• utvrdi strategiju preuzimanja međunarodnih i regionalnih standarda. 
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EDI kao elektronska razmena podataka obuhvata četiri osnovna procesa: 

• standardizaciju procedura komunikacija; 

• formatizovanje podataka u poruke koje se razmenjuju između računara; 

• prenos poruka; 

• prevođenje poruka u oblik koji omogućava obradu prenesenih podataka. 

Sistem EDI se tokom vremena razvio, kako u pogledu novih standarda tako i na 
području efikasnije zaštite za prenos podataka i novca. Na osnovu strogo definisanih 
standarda vrši se transfer „elektronskog novca“ i poslovnih poruka. EDI tehnologija sve 
više postaje uslov poslovanja na svetskom tržištu, koje teži da se ujedini u jedinstveno 
svetsko tržište na osnovu primene informatičkih dostignuća. Informatizacijom 
bankarskih i drugih finansijskih usluga globalni elektronski prenos sredstava postaje 
veza kompjuterizovanih banaka i drugih učesnica u platnom prometu. Osnovni problemi 
korišćenja novih tehnologija odnose se na opasnost od raznih vrsta neovlašćenog 
korišćenja i ,,upada“ u telekomunikacionu mrežu banke. Razvojem Intemeta i sve 
većom svetskom povezanošću došlo je do standardizacije elektronskih poruka sa ciljem 
bržeg i jednostavnijeg razumevanja različitih formata poruka. U okvim razvoja platnog 
prometa modelirani su dokumenti platnog prometa na bazi nacionalnih standarda. W3C 
(i World Wide Web Consortium ) predložio je OFX ( Open Financial Exchange ), koji je 
kreiran od strane softverskih kompanija CheckFree, Intuit i Microsoft početkom 1997. 
godine. da podrži veb transakcije i omogući povezivanje različitih korisničkih 
finansijskih softvera preko interfejsa. Baziran je na klijent/server i zahtev/odgovor 
modelu, definiše standarde u razmeni podataka finansijskih transakcija, omogućava 
finansijskim institucijama slobodan izbor platfonne za informacione tehnologije jer su 
definisani standardi u razmeni podataka koji su nezavisni od sistemskih softvera. Kao 
rešenje za elektronsku razmenu podataka OFX su koristile velike banke kao što su: 
Bank of America, Chas Manhattan Bank, Citibank. Pored banaka bile su uključene su i 
bankarske gmpacije, brokerske organizacije, osiguravajuća dmštva i softverske 
kompanije. Novije verzije OFX standardnih specifikacija bazirane su na XML jeziku 
(.Extensibile Markup Language). Svoju primenu OFX specifikacije našle su u velikim 
bankarskim mrežama (SWIFT), a sa transformacijom platnog sistema kod nas nameće 
se potreba primene XML-a u elektronskom platnom prometu [234], [33]. 

3.2.2 SWIFT i privatne mreže za razmenu poruka 

SWIFT - Society for Worldwide Interbank Financial Telecommunication je osnovan 
1973. godine sa ciljem kreiranja zajedničke svetske mreže za obradu podataka i 
komunikaciju, uz pronalaženje zajedničkog jezika za intemacionalne finansijske 
transakcije. SWIFT se pobrinuo da finansijske institucije između kojih će se 
razmenjivati pomke budu značajno uključene u proces razvoja mreže da bi se osigurala 
efikasnost i praktičnost. Još u ranoj fazi razvoja definisana su osnovna pravila na kojima 
se zasniva SWIFT, a to su sigumost, pouzdanost i odgovornost [206]. U Belgiji i 
Holandiji 1976. godine otvoreni su prvi operativni centri. Posle 12 meseci 
funkcionisanja akumulirani zbir obrađenih pomka je prešao cifm od deset miliona, što 
je predstavljalo pravu potvrdu i ogroman uspeh. Prvi operativni centar u SAD otvoren je 
1979. godine, a 1980. povezane su prve zemlje azijskog kontinenta i to su bile Hong 
Kong i Singapur. 

Povezivanje centralnih banaka učvrstilo je poziciju SWIFT-a kao zajedničkog kanala 
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između svih učesnika u bankarskom sektoru. SWIFT je 1985. godine instalirao satelitski 
link koji će povezivati operativne centre SAD i Evrope da bi se podržao porast broja 
razmenjenih poruka i nivo usluga putem satelitske komunikacije. Sistem SWIFT-a 
dobija nagradu 1991. godine Smithsonian instituta za oblast informacionib tehnologija, 
kojom se konstatuje da bi bez postojanja njegovog sistema finansijske institucije bile 
ograničene na kombinaciju papimih dokumenata i nekompatibilnih privatnih mreža, što 
bi umnogome ograničilo njihovu sposobnost da prate razvoj međunarodnih finansijskih 
tokova. Interbank File Transfer (IFT), AccordIVorkstation, SWIFTAsset Reconciliation, 
SWIFT-AUiance neki su od novih proizvoda i usluga koji su lansirani do 1994 godine. 
Model straight-through processing (STP) razvija se 1996. godine. Ovim modelom 
snižavaju se troškovi, upravlja se rizikom i poboljšava se automatizacija. SWIFT takođe 
podržava inicijative za razvoj tržišne infrastmkture u domenu clearing- a, settlement- a i 
trgovine. 

Uvođenje evra 1999. godine uslovljava mnoga prilagođavanja u okvim raznih 
kategorija pomka. SWIFT počinje razvoj standarda sledeće generacije i strategije koja 
se odnosi na e-poslovanje. SWIFT sistem 2000. godine objavljuje planove za dva 
servisa koji podržavaju prelazak na „ business-to-business ” domen. To su servisi Trust 
Act koji osigurava korporativno trgovanje preko Intemeta i e-paymentsPlus koji 
korporacijama sa veb baziranim plaćanjima omogućava siguran servis. SWIFTNet 
messaging services prvi put počinje da funkcioniše 2001. godine implementacijom u 
okvim domaće tržišne infrastmkture i to u okvim RTGSPlus sistema Centralne banke 
Nemačke i Centralne banke Engleske. 

Koncepcija SWIFT sistema sastoji se od različitih sistemskih celina, odnosno 
tehnoloških nivoa mreže, čija hijerarhija uslovljava hardware, software, komunikacionu 
stmktum mreže i međusobne kontrolne relacije i veze. Svaka od pojedinih sistemskih 
celina sprovodi određeni deo funkcija: Svstem Control Processor (SCP), Slice 
Processors (SP), Regional Processors (RP), SWIFT Access Point (SAP), Gateway 
Computer. Svstem Control Processor se nalazi u središtu SWIFT sistema. U okvim ove 
mreže postoje dva SCP u Americi i dva u Holandiji. Međutim, uvek je aktivan samo 
jedan od njih. Zadatak SCP je da kontroliše sve pristupe sistemu i obavlja monitoring 
kompletne SWIFT mreže i njenih servisa, kao i distribuciju novog software- a, kontrolu 
ponovnog uspostavljanja veze i stanja posle prekida u mreži i sl. U SWIFT mreži 
postoje dva Slice Processor -а od kojih je uvek aktivan samo jedan. Slice Processor 
predstavlja deo SWIFT sistema koji komunicira sa korisničkim logičkim terminalom 
(LT). Zadatak SP-a jeste da usmerava pomke između pojedinih korisnika SWIFT-a 
preko regionalnih procesora, da čuva kopije svih emitovanih pomka i na zahtev 
korisnika ispostavlja kopiju takvih poruka, da generiše sistemske pomke. Svaki 
Regional Processor logički predstavlja ulaznu i izlaznu tačku SWIFT sistema. Svi 
korisnici pristupaju SWIFT mreži preko regionalnog procesora. Svaku unetu i 
emitovanu pomku proverava regionalni procesor, pre nego što se uputi na svoj dalji put, 
prema Slice Processor-u. Isto tako i sve dolazeće pomke jedno vreme se zadržavaju u 
odgovarajućem regionalnom procesom, koji sprovodi kontrolu pomka, a zatim ih 
ispomčuje na naznačenu adresu. SWIFT Access Point - SAP su mrežni konekcioni 
čvorovi koji podržavaju portove kroz koje omogućavaju korisnicima fizički pristup 
SWIFT mreži. Sastoje se od telekomunikacione opreme koja je pod nadzorom SWIFT-a 
sa lokalnom podrškom koju obezbeđuju lokalni ugovarači SAP-a, kojih ima nekoliko u 
jednoj zemlji, a neke manje zemlje su priključene na SAP u susednoj zemlji. 


Slobodan Babić \ Fakidtet organizacionih паика 


56 



Doktorska disertacija: Model interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama 


Široka rasprostranjenost i veliki broj učesnika uslovili su da SWIFT dobije primat nad 
ostalim telekomunikacionim sredstvima, pa su tako došle do izražaja mnogobrojne 
prednosti korišćenja SWIFT mreže. Prednosti upotrebe SWIFT-a posmatrano sa aspekta 
troškovne efikasnosti jesu sledeće: omogućava jedinstven pristup raznim finansijskim 
institucijama i sistemima, vremenski rok prijema - kruženja poruka maksimalno je 
skraćen, platfonna za kreiranje poruka se može višestruko upotrebljavati, široka je skala 
usluga po pristupačnoj ceni, standardi koji se koriste podržavaju automatizaciju i brzu 
obradu poruka, smanjeni su troškovi prenosa poruka u odnosu na teleks i poštu, 
poboljšan cash management jer su informacije koje se dobiju ažume što omogućava 
bolje iskorišćenje sredstava. 

Prednosti upotrebe SWIFT-a, posmatrano sa aspekta upravljanja rizikom: mrežna 
elastičnost sistema kroz dupliranje opreme i linija, mrežna sigumost sistema, 
bezbednost prenosa pomka kroz autentifikaciju, detekciju, segregaciju saobraćaja i 
enkripciju, što znači da neovlašćeni korisnici ne mogu koristiti mrežu, smanjen 
operativni rizik kroz brzu obradu podataka, efikasna kontrola prilikom emitovanja i 
umčenja. Posmatrano sa aspekta poslovnog kontinuiteta SWIFT je pokazao vodeću 
poziciju u poslovnom kontinuitetu sa skoro stoprocentnom raspoloživošću iz godine u 
godinu jer SWIFT je mreža operativna 24 sata svakog dana širom sveta. 

SWIFT mreža svojim korisnicima omogućava: potpunu automatizaciju platnih procesa, 
primenom standardnog jezika komunikacije, smanjenje rizika kod plaćanja, povećanje 
pouzdanosti i tajnosti poruke između primaoca i pošiljaoca, promptni prenos pomke, 
povezanost sa bankama širom sveta, automatske sisteme razmene šifara i odgovarajućih 
ključeva, efikasnije upravljanje sredstvima, automatsku obradu podataka dnevno 
poravnavanje prometnih transakcija i dnevnu kontrolu stanja, kontrolisanje i smanjenje 
troškova poslovanja [208]. 

SWIFT standardi su striktno definisana pravila i formati popunjavanja polja u okvim 
standardizovanih SWIFT pomka, odnosno opisi odgovarajućih procedura koje se 
moraju do detalja sprovesti da bi se omogućilo normalno funkcionisanje SWIFT sistema 
i razmena odgovarajućih pomka u okviru mreže. Svi standardi precizno su definisani i 
tekstualno opisani sa odgovarajućim ilustracijama. Poštovanjem standarda pomka 
moguće je kreirati, memorisati i emitovati pomke uz odgovarajuću validaciju i 
autorizaciju. Razmena SWIFT pomka podvedena je pod stroga pravila standarda 
(međunarodno priznatih), a stmktura pomka je u korelaciji sa vrstom i tipom 
bankarskog instmmenta koji se u suštini mapira (po utvrđenim pravilima mapiranja 
sadržaja pomka). Standardi nad pomkama znače jedinstvena pravila interpretacije 
pomka, odnosno sve članice SWIFT mreže na isti način tumače sadržaj pomka koje 
razmenjuju sa ciljem izvršavanja plaćanja/naplata u poslovima sa inostranstvom. 

SWIFT tehnologija rada, u odnosu na tradicionalni sistem rada, omogućava: 
unificiranost jezika komunikacije i postupaka, ažuran prenos pomka, veći stepen 
pouzdanosti i tajnosti u prenosu transakcija, efikasniju kontrolu postupka plaćanja, 
direktno povezivanje sa bilo kojom bankom koja se nalazi u SWIFT mreži, znatno veću 
efikasnost upravljanja sredstvima, automatizovanu obradu podataka i smanjenje 
troškova poslovanja. Standardizovana SWIFT tehnologija rada ima za krajnji cilj veću 
efikasnost upravljanja sredstvima. U svom razvoju SWIFT se ograničio na transfer 
sredstava između banaka, što je samo po sebi izuzetno značajno za efikasniji razvoj 
banke. Korišćenje ove tehnologije, u smislu automatizovanja radnih postupaka i 
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procedura, koje se odnose na disponiranje deviznih sredstava i upravljanje deviznim 
sredstvima, pruža značajnu mogućnost unapređenja poslovanja banke. Unificiranost 
jezika komunikacije i postupaka odnosi se na uspostavljanje SWIFT standarda za 
komuniciranje i utvrđivanje kategorija poruka za bankarske linansijskc transakcije. 

U postupku slanja i primanja poruke ugrađene su procedure i kontrole koje garantuju 
sigurnost prenosa. Banka koja šalje poruku brine o unosu podataka u SWIFT računarsku 
mrežu, u formi i na način kako je to utvrđeno propisanim fonnatima, zatim vrši 
autentifikaciju, tj. šifriranje koje se obavlja automatizovano od strane računara na 
osnovu razmenjenih ključeva između korespodentskih banaka. Zatim sledi formiranje 
ISN - a ( Input Sequence Number - ulazni sekvencijalni broj koji računarski sistem 
banke pošiljaoca formira za svaku ulaznu poruku) i puštanje poruke. Regionalni 
procesor proverava protokol i postupak enkripcije i klasifikaciju poruke. Operativni 
centar proverava ISN i format, arhivira poruku i formira OSN, tj. izlazni sekvencijalni 
broj koji je sastavni deo ORN - Output Reference Number), koga sadrži svaka dolazeća 
poruka, a sastoji se od izlaznog datuma, identifikacije izlaznog terminala, koda banke i 
OSN-a. Regionalni procesor u zemlji primaoca poruke obavlja deskripciju, klasifikaciju 
poruke i proverava protokol. Banka, primalac poruke, kontroliše prijem, kontroliše OSN 
i autentifikaciju, vrši klasifikaciju i distribuciju poruke. 

SWIFT povezuje sve banke korisnike ove tehnologije rada i pruža im nedvosmislene 
prednosti u poslovanju. SWIFT tehnologija rada omogućava integraciju i potpunu 
automatizaciju radnih procedura. Kroz SWIFT mrežu vrši se realizacija plaćanja [178], 
po mehanizmima sistema razmene poruka. Organizacija mreže ima trostepenu 
arhitekturu, odnosno prvi stepen je nivo korisnika i programski interface prema SWIFT 
mreži; drugi stepen je SWIFT administracija i mreže računara koje u okviru SWIFT 
tehnologije podržavaju rad korisnika (banaka i drugih finansijskih institucija, brokerskih 
kuća, klirinških kuća, centralnih banaka), sada već i kompanija kao članova SWIFT 
mreže; treći stepen je SWIFT mreža sa svim osnovnim i value added servisima, koja 
funkcioniše danas kao IP mreža u sistemu SWIFTNet FIN aplikacija kao bazni servis 
razmene poruka i nizom interaktivnih servisa mreže sa svim potrebnim 
funkcionalnostima za neposredni rad korisnika SWIFT mreže [234]. 

U SWIFT tehnologiji referenciranje poruka predstavlja mehanizam kontrole emitovanih 
i primljenih poruka. Model poslovnih funkcija integriše se putem razvoja lokalnih baza 
podataka i pojedinačnih aplikativnih segmenata, uz uvažavanje pravila i SWIFT 
standarda. Na taj način ostvaruje se informatički model SWIFT-a, koji obezbeđuje: 
podršku međunarodnom platnom prometu [177], u pogledu transfera poruka, i 
integraciju poslovnih funkcija platnog prometa i disponibiliteta deviznih sredstava 
banke. U tehničkom smislu, SWIFT mreža kao autonomna mreža integriše se u 
računarsku mrežu banke, izgrađenu na principima integrisane arhitekture. 

SWIFT posebno obraća pažnju na bezbednost mreže. U tom smislu, razvijene su usluge 
vezane za bezbednost mreže pod nazivom USE Project (User Securitv Enhagement), a 
odnose se na: bilateralnu razmenu ključeva kojom je omogućena razmena ključeva, 
utvrđivanje ispravnosti prenosa poruke i sigurnosno prijavljivanje na mrežu korišćenjem 
IC kartice. Ključni proizvod SWIFT-a (pored Messaging Services) je SWIFTNet Y- 
COPY servis kao bazna infrastruktura za Sistem velikih plaćanja - SVP (RTGS), koji se 
ugrađuje u nacionalne i transnacionalne sisteme veliki plaćanja i predstavlja nukleus 
tehnologije upravljanja i regularnim servisima i rizicima u sistemu velikih plaćanja [23]. 
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3.2.3 Standardi ISO15022 i IS020022 

ISO 20022 [99] - UNIversal Financial Industrv Message scheme (UNIFI) je 
internacionalni standard, naslednik standarda ISO15022 [208], koji dclinišc ISO 
platfonnu za razvoj finansijskih standarda. Pristup prisutan u šemama poslovnog 
modeliranja omogućava korisnicima i informatičarima da prezentuju finansijske 
poslovne modele i pripadajuće transakcije sa fonnalnom sintaksno nezavisnom 
notacijom. Ovi poslovno-transakcioni modeli su stvami poslovni standardi. Oni mogu 
biti prevedeni u fizičke poruke željene sintakse. U vreme kada je UNIFI počeo sa 
razvojem, XML ( eXtensible Mark-up Language) je već bio vodeća sintaksa za e- 
komunikaciju. 

Prvi fokus UNIFI je internacionalna finansijska komunikacija između finansijskih 
institucija, njihovih klijenata i domaća ili internacionalna infrastmktura uključena u 
procesiranje finansijskih transakcija. U tu svrhu je razvijen i repozitorijum, kao i skup 
standardizovanih šema pomka koje se nalaze na IS020022 sajtu. 

Standard u sebi sadrži i metodologiju razvoja, registracioni proces i organizaciju 
centralnog finansijskog repozitorijuma koji sadrži UNIFI pomke i njihove komponente. 
Navedeni UNIFI standard se sastoji od pet delova: 

• Part 1: Overall methodologv and format specifications for inputs and output 
from the IS020022 Repositorv (Prvi deo: Opšta metodologija i specifikacija 
formata za izmenu i pregled IS020022 repozitorijuma); 

• Part 2: Roles and responsibilities of the registration bodies (Dmgi deo: Uloga i 
odgovornosti registracionih tela); 

• Part 3: IS020022 modelling guidelines (Technical Specification ) (Treći deo: 
IS020022 vodič za modelovanje (tehnička specifikacija)); 

• Part 4: IS020022 XML design rules (Technical Specification ) (Četvrti deo: 
IS020022 pravila za dizajniranje (tehnička specifikacija)); 

• Part 5: IS020022 reverse engineering (Technical Specification ) (Peti deo: 
IS020022 reverzni inženjering (tehnička specifikacija)). 

Ako ne postoje UNIFI pomke koje pokrivaju specifične transakcije, može se 
inicijativom definisati novi model i pomke koje će odobriti UNIFI registraciono telo. 
Ako pomka postoji u repozitorijumu, ali ne zadovoljava sve potrebe, može se 
inicijativom kreirati nova verzija pomka koja će ih prilagoditi potrebama. 

U tabeli 4. prikazan je opis dela sadržaja IS020022 sajta koji se odnosi na platne 
pomke. Da bi ISO definisao poruke i da bi ih učinio javnim dobrom objavljene su sve 
UNIFI pomke sa svim elementima koje ih opisuju: 

• dokument u pdf fonnatu koji u potpunosti opisuje pomke; 

• XML šema svih pomka; 

• poslovni primeri, odnosno XML instance svake pomke; 

• zip fajl koji sadrži HTML verziju UML modela pomka; 

• zip fajl koji sadrži UML model pomka, koji je u potpunosti otvoren i može da se 
koristi sa IBM Rational Rose 8.5.0506.2811; 

• zip fajl koji sadrži aktiviti dijagrame (za poslovne tokove), dijagrame sekvenci 
(za izradu scenarija) i dijagrame klasa (za poruke). Dijagrami su dostupni u više 
formata. 
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UNIFI Payments Messages 

This section gives access to the description of UNIFI Payments messages in the follovving business areas 


Message Name 

Msg П) (ХАП 
Schema) 

XML 

Instances 

Msg I)ef 
Report 

Model 

Diagrams 

Custo m erCre ditTran s ferlnitiation V02 

pain. 001.001.02 

Download 

Download 

(1.3MB) 

HTML 

(47.8MB) 

Rose 

Download 

(1.7MB) 

®P aym e ntS tatus Rep ortV 0 2 

pam.002.001.02 

Downloađ 

P ау m e ntC anc e 11 ati o nRe que st V 01 

pam.006.001.01 

Download 

Custo m erP aym e ntRe ver s al V 01 

pam.007.001.01 

Download 

(4.5MB) 

Custo m erD lrectD eb ltlmti atio n V01 

pam.008.001.01 

Downloađ 

Payments Clearin<| and Settlement 



Message Name 

Msg П) (Х1\П 
Scheina) 

XML 

Instances 

Msg I)ef 
Report 

Model Diagrams 


PaymentStatusReportV02 
FIToFICustomerDirectDebitVOl 
P ау m e ntReturnV 01 
PaymentCancellationRequestVO 1 
FIT oFIP ау m e ntRe ver sal VO1 


pacs.002.001.02 


pacs.003.001.01 


Download 


Download 


pacs.004.001.01 Download 


Download 


pacs.006.001.01 Download n 7MB) 


pacs.007.001.01 Download 


HTML 

(46.7MB) 

Rosem 

(4.5MB) 


FIT oFIC us to merCre ditTrans fe rVO 1 


pacs.008.001.01 Download 


FinanciallnstitutionCreditTransferVOl pacs.009.001.01 [Download 


Download 

(2.4 MB) 


Cash Mana«jement. Bank-to-Ciistomer Casli fvlanagement 


Message Name 

BankToCustomerAccountReportVOl 
BankToCustomerStatementVO 1 


Rlsg ID (NML XML Msg I)ef 
Schema) Instances Repoit 


Model Diagjams 


camt.052.001.01 Download 


camt.053.001.01 Download 


Download 

(1.8MB) 


BankToCustomerDebitCreditNotificationVOl camt.054.001.01 Download 


HTML 

(42.3MB) 

Rose 

(4.4MB) 


Download 

(0.3MB) 


Message Name 

Msg П) (Х1\П 
Scliema) 

XML 

Instances 

RequestToModifyPayment 

camt.007.002.01 

Download 

RequestToCancelPayment 

camt.008.002.01 

Download 

UnableToApply 

camt.026.001.01 

Download 

ClaimN o nRe c e ip t 

camt.027.001.01 

Download 

Additi o nalPayme ntlnform ati o n 

camt.028.001.01 

Download 

ResolutionOflnvestigation 

camt.029.001.01 

Download 

Notifi c atio nO fCas e As s lgnm e nt 

camt.030.001.01 

Download 

RejectCaseAssignment 

camt.031.001.01 

Download 

CancelCas eAs signment 

camt.032.001.01 

Download 

Reque s tF orDup li c ateln struc tion 

camt.033.001.01 

Download 

DebitAuthorisationRe sponse 

camt.036.001.01 

Download 

DebitAuthorisationRequest 

camt.037.001.01 

Download 

C aseStatus Rep ortR e que st 

camt.038.001.01 

Download 

CaseStatusReport 

camt.039.001.01 

Download 


Msg I)ef 
Repoit 


Model Diagjams 


Download 

(0.7MB) 


HTML 

(53.4MB) 

Rose 

(4.6MB) 


Download 

(1.6MB) 


Tabela 4. Platne poruke UNIFI formata za poslovne procese plaćanja 
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Spisak UNIFI poruka u odnosu na domen primene: 

• plaćanja ( Pavments ); 

• notifikacije za inostrana plaćanja (FOREXNotification); 

• hartije od vrednosti ( Securities); 

• trgovačke poruke ( Trade Services). 

Oslanjajući se na IS020022 standard za poruke, u skladu sa svojim potrebama EPC je 
dodatno definisao odgovarajući set poruka i na taj način napravio svoju modifikaciju 
IS020022 standarda, koju će u platnom prometu da koriste banke, druge finansijske 
institucije i korisnici finansijskih usluga na malo. I dosadašnja praksa korišćenja poruka 
bila je ista. Narodna banka Srbije je, na primer, definisala svoj set poruka 2003 godine 
na bazi SWIFT poruka sužavajući mogućnost korišćenja poruka, tj. definisanjem svog 
podstandarda. Podstandard se definiše da bi se suzila upotreba zadatog seta poruka u 
smislu jasnije implementacije, lakše kontrole tokova poruka i drugih sličnih razloga. 

U tabeli 5. predstavljen je skup osnovnih EPC poruka koje mogu da se preuzmu sa EPC 
sajta, i koje se redovno ažuriraju. Skraćenica ,,pacs“ označava da je u pitanju poruka za 
plaćanje - payment, a cs potiče od reči clearing (poravnanje) i settlement (izvršenje). U 
nizu brojeva koji sledi xxx.yyy.zz, ххх označava vrstu poruke (originalni broj koji je na 
odgovarajućoj ISO poruci), ууу definiše upotrebu poruke, a zz verziju. 


Naziv poruke 

Ime fajla sa xsd šemom 

FIToFICustomerCreditTransfer.EPCCoreV02 

$pacs.008.002.02.xsd 

FIToFICustomerDirectDebit.EPCCoreV02 

$pacs.003.002.02.xsd 

PaymentStatusReport.EPCCoreV02 

$pacs.002.002.02.xsd 

PaymentReturn.EPCCoreV02 

$pacs.004.002.02.xsd 

FIToFIPaymentReversal.EPCCoreV02 

$pacs.007.002.02.xsd 


Tabela 5. EPC osnovni set poruka 

U tabeli 6. prikazane su osnovne poruke koje u sebi imaju definisane i dodatne opcione 
servise. Dodatni opcioni servisi su one usluge finansijskih organizacija koje nisu 
obavezne, koje mogu da donesu prihod ili privuku klijente i finansijske institucije su 
dužne da ih, ukoliko su ih uvele zbog određenog broja klijenata, pružaju i ostalim 
svojim klijentima bez diskriminacije. Ovakav pristup determinisanja upotrebe servisa 
omogućen je zahvaljujući prednostima koje pružaju savremene informacione i 
komunikacione tehnologije. Naime, ukoliko je ICT servis uveden za određen broj 
subjekata, samo administrativne zabrane (a ne troškovi) mogu da onemoguće primenu 
istih servisa i za ostale. 


Naziv poruke 

Ime fajla sa xsd šemom 

FIToFICustomerCreditTransfer.EPCCoreAOSV02 

$pacs.008.003.02.xsd 

FIToFICustomerDirectDebit.EPCCoreAOSV02 

$pacs.003.003.02.xsd 

PaymentStatusReport.EPCCoreAOSV02 

$pacs.002.003.02.xsd 

PaymentReturn.EPCCoreAOSV02 

$pacs.004.003.02.xsd 

FIT oFIPaymentReversal. EPC C ore AO S V 02 

$pacs.007.003.02.xsd 


Tabela 6. EPC osnovni set poruka sa definisanim dodatnim opcionim servisima 
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3.2.4 Standardi Banke za međunarodna poravnanja 

Sa ciljem uvođenja standarda i tehnološkog reda formiran je Komitet Banke za 
međunarodna poravnanja (Вапк for International Settlements - BIS) u Bazelu (BIS 
CPSS - Committee for Pavments and Settlement Systems ) koji je dclinisao metodologiju 
sistematizovanu u 10 osnovnih principa za sistematski značajne platne sisteme (BIS 
Core Principles for Systematically Important Pavment Svstems ) [23], [28], [37] koji 
imaju snagu preporuka. Praksa je potvrdila značaj preporuka u više od 40 zemalja. 
Primena principa, u procesu pripreme, projektovanja i implementacije sistema plaćanja 
(RTGS) vrlo je efikasna, pouzdana i produktivna metodologija, u smislu metodologije i 
dcfinicija 10 osnovnih principa za sistemski važne sisteme plaćanja. 

Ključni princip u primeni osnovnih principa ( Core principles) zasnovan je na 
deflnisanju razlike sistemski važnih sistema plaćanja i onih koji to nisu. U svakoj zemlji 
postoji uvek više sistema plaćanja koji su bitni za njihove korisnike, vrlo značajni za 
funkcionisanje poslovnih subjekata i izvršavanje njihovih finansijskih obaveza. Prema 
tački 6.66 osnovnih principa, samo oni sistemi plaćanja koji mogu da upravljaju 
regulamim tokovima plaćanja, finansijskim poremećajima, upravljaju rizikom i 
iznenadnim finansijskim udarima, njihovim prenosom i kontrolom u platnom prometu u 
zemlji, ali i inostranstvu, mogu se nazvati sistemski važnim sistemima plaćanja. Pored 
navedenih karakteristika, još znatan deo uslova (zakonskih i tehnoloških) mora da 
ispuni svaki sistemski važan sistem plaćanja (RTGS). 

Definisanje metodologije za poštovanje osnovnih principa i njihovu implementaciju ima 
za cilj korišćenje univerzalnih uputstava i preporuka radi projektovanja i funkcionisanja 
bezbednijih i značajno efikasnijih sistemski važnih sistema velikih plaćanja u svetskoj 
ekonomiji. Poseban značaj implementacije osnovnih principa vezan je za zemlje u 
tranziciji gde postoji potreba za konsolidacijom i harmonizacijom SVP i u kojima se 
značajno povećavaju i broj transakcija i obimi plaćanja koji se emituju i primaju u 
platnom prometu u zemlji i međunarodnom platnom prometu, odnosno nacionalnim i 
svetskim finansijskim tržištima. 

U sistemima velikih plaćanja koji su od interesa za Banku za međunarodna poravnanja, 
ključni instrumenti plaćanja su prenosi sredstava i direktno zaduženje [145]. Drugi 
instrumenti plaćanja: plaćanje platnim karticama, plaćanje čekovima [132], i internet 
plaćanja u principu su karakteristični za sisteme malih plaćanja i nisu od interesa za 
Banku za međunarodna poravnanja. U nastavku je 10 osnovnih principa Banke za 
međunarodna poravnanja: 

I Sistem treba da ima dobru zakonsku osnovu po svim relevantnim 
nadležnostima. 

II Pravila i procedure sistema treba da omoguće učesnicima jasno 
razumevanje uticaja sistema na sve finansijske rizike koje učesnici trpe 
učestvujući u sistemu. 

III Sistem treba da ima jasno definisana pravila za upravljanje kreditnim 
rizikom i rizikom likvidnosti, koja specificiraju odgovomosti operatora 
sistema i učesnika i koja predviđaju odgovarajuće mogućnosti za 
upravljanje i sprečavanje tih rizika. 
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IV Sistem treba da omogući promptno konačno plaćanje na dan valute, 
ukoliko je moguće tokom dana, a minimalno na kraju dana. 

V Sistem u kome se radi multilateralno neto poravnanje mora, minimalno, 
da osigura pravovremeno izvršenje dnevnih poravnanja, čak i kada 
učesnik, sa najvećim pojedinačnim neto obavezama, nije u mogućnosti 
da izvrši plaćanja. 

VI Sredstva koja se upotrebljavaju za poravnanje treba da glase na centralnu 
banku; ukoliko se koriste druga sredstva, ona smeju da budu izložena 
minimalno ili bez kreditnog rizika i minimalno ili bez rizika likvidnosti. 

VII Sistem treba da ima visok stepen sigumosti i operativne pouzdanosti i da 
ima obezbeđenu opremu i procedure za kontinuirano obavljanje dnevnih 
obrada i blagovremeni završetak dnevne obrade. 

VIII Sistem treba da omogući sredstva za izvršenje plaćanja koja su praktična 
za korisnike i efikasna za poslovanje. 

IX Sistem treba da ima objektivne i javno objavljene kriterijume za učešće, 
koji predviđaju ravnopravan i slobodan pristup. 

X Aranžmani za upravljanje sistemom moraju biti efektivni, transparentni i 
kontrolabilni. 

Odgovornosti centralne banke u primeni Osnovnih principa se odnosi na jasno 
definisanje ciljeva svog sistema plaćanja i da javno objavi njegovu ulogu i politiku u 
skladu sa definisanim Osnovnim principima, da obezbedi da sistem kojim upravlja 
funkcioniše u skladu sa Osnovnim principima, da vrši kontrolu sistema za plaćanje 
kojima ne upravlja,u skladu sa Osnovnim principima, i da saglasno principima izvršava 
potreban nadzor. Centralna banka, sa ciljem promocije bezbednosti i efikasnosti svog 
sistema plaćanja, koji fu nk cioniše na bazi Osnovnih principa, treba da sarađuje sa 
drugim centralnim bankama i svim nadležnim domaćim i inostranim autoritetima. 

3.2.5 Zakonski okvir za procesorske kuće u Srbiji 

Prema novom nacrtu zakona o platnim uslugama u Republici Srbiji, što može da se 
smatra savremenim gledištem Direkcije za platni promet Narodne banke Srbije [128], 
platni sistem je sistem za prenos novčanih sredstava koji ispunjava sledeće uslove: da je 
sporazum u pisanoj formi na osnovu kojeg se uspostavlja platni sistem zaključen 
između najmanje tri učesnika, ne uključujući indirektnog učesnika, da najmanje jedan 
učesnik - pružalac platnih usluga ima sedište u Republici Srbiji i da ima zajednička 
pravila rada i standardizovane procedure za kliring ili poravnanje naloga za prenos 
između učesnika [134]. Učesnici u platnom sistemu mogu biti investiciono društvo iz 
RS i investiciono društvo iz EU, pravno lice sa sedištem u trećoj državi koje obavlja 
poslove koji odgovaraju poslovima KI ili investicionog društva, organi javne vlasti u 
RS, kao i privredno društvo i drugo pravno lice čiji je osnivač RS, autonomna pokrajina 
ili jedinica lokalne samouprave za čije obaveze po zakonu jemči RS, država članica, 
ECB, CB države članice, organi javne vlasti za čije obaveze po zakonu jemči država iz 
EU, posebne nacionalne kreditne institucije koje su izuzete propisom Evropske unije 
kojim se uređuje osnivanje i poslovanje KI, operator drugog platnog sistema i sistema 
za poravnanje HoV [138], [143]. 
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3.2.6 Usaglašavanje Srbije sa Evropskom unijom 

Narodna banka Srbije intenzivno sprovodi brojne aktivnosti na usaglašavanju 
nacionalne regulative s propisima Evropske unije iz oblasti platnih sistema. Kao rezultat 
tih aktivnosti, izrađeni su Nacrt zakona o platnim uslugama i Nacrt zakona o konačnosti 
poravnanja u platnim sistemima i sistemima za poravnanje hartija od vrednosti [149]. 
Reč je o usklađivanju sa osnovnim direktivama Evropske unije [61] ( Directive 
2007/64/EC on pavment services in the internal market, Directive 98/26/EC on 
settlement jinalitv in payment and securities settlement systems i Directive 2009/1 10/EC 
on the taking ир, pursuit and prudential supervision of the business of electronic топеу 
institutions ) kojima se stvara usklađen, moderan i sveobuhvatan set pravila za pružanje 
platnih usluga na nivou Evropske unije. 

Direktiva o platnim uslugama ( Directive 2007/64/EC on pavment services in the 
internal market ) - PSD, pored toga što pruža pravnu osnovu za stvaranje jedinstvenog 
evropskog tržišta za pružanje platnih usluga, čime se podstiče veća efikasnost i 
smanjenje troškova, predstavlja i skup pravila kojima je cilj da se unapredi konkurencija 
u ovoj oblasti otvaranjem tržišta plaćanja za nove učesnike - platne institucije. Takođe, 
Direktiva pruža neophodnu pravnu osnovu za sprovođenje SEPA projekta. 

Direktiva o konačnosti poravnanja i platnim sistemima i sistemima hartija od vrednosti 
(Directive 98/26/EC on settlementfinality in payment and securities settlement svstems ) 
- SFD pravnu sigurnost u platnima sistemima u slučaju pokretanja postupaka kao što su 
stečaj, likvidacija i sl. nad nekim od učesnika u sistemu, čime se sprečava širenje 
sistemskog rizika na druge učesnike u sistemu. 

Direktiva o osnivanju, poslovanju i prudencijalnoj superviziji institucija koje izdaju 
elektronski novac (e-novac) (Directive 2009/1 10/EC on the taking up, pursuit and 
prudential supervision of the business of electronic топеу institutions) - 2EMD 
uspostavlja pravni okvir za izdavanje e-novca, s ciljem da se omogući razvoj ovog 
tržišta i pojava novih, inovativnih i pouzdanih servisa e-novca kao tehnološke inovacije 
u oblasti platnih sistema koja pospešuje konkurenciju u pružanju platnih usluga. E- 
novac je digitalni ekvivalent za gotovinu smešten na elektronskom uređaju ili na 
udaljenom serveru, i označava elektronski ekvivalent, uključujući magnetno pohranjenu 
novčanu vrednost koja predstavlja novčano potraživanje prema izdavaocu tog novca, a 
izdata je nakon prijema novčanih sredstava (radi izvršavanja platnih transakcija) i 
prihvata je fizičko ili pravno lice koje nije izdavalac tog novca. Uobičajeni oblici e- 
novca su „elektronski novčanik“ u vidu smart kartice na kojoj je smeštena određena 
novčana vrednosti, po pravilu relativno manjeg iznosa, zatim e-novac pohranjen na 
mobilnom telefonu ili na računu na intemetu. 

3.3 Primeri platnih sistema 

3.4 Platni sistemi u svetu 

Platni sistemi u Austriji 

Ekonomija Austrije je tesno povezana sa ekonomijama dmgih zemalja Evropske unije, 
posebno sa ekonomijom Nemačke. Ova zemlja ima veoma snažne ekonomske veze sa 
zemljama u Centralnoj, Istočnoj i Jugoistočnoj Evropi, te joj je takva pozicija u regionu 
omogućila da postane atraktivno investiciono tržište. Austrija je ušla u Evropsku 
ekonomsku i monetamu uniju 1999. godine i bila je jedna od prvih zemalja koje su se 
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odlučile za ulazak u Target2 RTGS sistem u novembru 2007. godine. 

Centralna banka. Oesterreichische Nationalbank (OeNB) [33], [234] je centralna 
banka Republike Austrije i predstavlja sastavni deo evropskog sistema centralnih 
banaka ( European System of Central Banks - ESCB ) kao i euro-sistema (Eurosvstem). 
Centralna banka daje svoj doprinos donošenju odluka o monetarnoj i ekonomskoj 
politici u Austriji i u evrozoni. U skladu sa Saveznim zakonom o Nacionalnoj banci 
Austrije (1984. - Nationalbank Act - NBG ), Centralna banka Austrije je akcionarsko 
društvo. Uzimajući u obzir status centralne banke, nju reguliše određeni broj posebnih 
odredbi Zakona o Centralnoj banci Austrije. Kapital Centralne banke Austrije iznosi 
EUR 12 miliona, pri čemu je 70% u vlasništvu Savezne vlade dok je 30% u vlasništvu 
organizacija poslodavaca i zaposlenih, kao i banaka i osiguravajućih kompanija. 

Platni sistem. Platni sistem u Austriji karakteriše razgranata mreža filijala banaka i 
šaltera pošte, kao i veliki broj posebnih platnih proizvoda. Infrastruktura platnog 
sistema sadrži jednoobrazne sisteme za obradu platnih transakcija tradicionalnim 
instrumentima, kao što su kreditni transferi ili direktna zaduženja, i za sve veći broj 
načina elektronskog plaćanja. Centralna banka Austrije aktivna je kod svake vrste 
unapređenja platnog sistema koji je od značaja za ekonomiju, posebno vodeći računa o 
pitanjima efikasnosti i sigumosti. Centralna banka isto tako vodi Sistem za 
međubankarske transfere (Austrian Real-time interbank selement - Artis). Za 
međubankarska plaćanja u Retail- u, koja su regulisana na nivou EU, OeNB je direktan 
učesnik u sistemu Step2. Time je svakoj austrijskoj komercijalnoj banci omogućen 
pristup Step2 sistemu, kao indirektnom učesniku preko Centralne banke Austrije. OeNB 
je razvila i vodi sistem Step.AT za kliring i neting domaćih plaćanja u Retail-u, koji je 
počeo da funkcioniše u julu 2007. godine. Ovo pruža alternativu tradicionalnom sistemu 
korespondentskog bankarskog poslovanja i austrijskim i regionalnim bankama 
obezbeđuje infrastrukturu u skladu sa SEPA. 

Asocijacija za istraživanje saradnje u oblasti plaćanja. Research Association for 
Pavment Cooperation (Stuzza) funkcioniše u istom svojstvu kao evropski Odbor za 
platni promet. U svojini je Centralne banke Austrije i najvećih poslovnih banaka u 
zemlji. Glavni zadatak mu je da razvija efikasne operativne pristupe za platne 
transakcije, kao i da postiže usaglašenost po pitanju zajedničkih standarda. Do sada 
realizovani projekti pokrili su logistiku poslovanja sa efektivom, elektronske potpise, 
mobilno bankarstvo, sisteme izvršenja velikih naloga za plaćanja kao i elektronsko 
bankarstvo. Stuzza takođe koordinira sve SEPA aktivnosti austrijskih banaka. 

Artis. Artis je počeo svoj operativni rad kao austrijska komponenta Targeta. Ne postoje 
nikakva ograničenja po pitanju vrste ili veličine plaćanja koje može biti podneto Artis-u. 
Komunikacija u okviru ovog sistema obavlja se preko SWIFT mreže. Aplikacija e- 
Konto omogućava fleksibilan pristup Artis-u, kao i informacijama u vezi sa likvidnošću. 
Učesnici u ovom sistemu mogu pristupiti informacijama preko intemeta uz uslov da 
poseduju certifikate o bezbednosti na serverima ili koriste SwiNet Browse i SwiNet 
Interact. Učesnici takođe mogu da koriste e-Konto radi slanja platnih naloga Artis- u uz 
korišćenje elektronskog potpisa. Banke licencirane u Austriji, kao i one sa sedištem u 
evropskoj ekonomskoj zoni (učesnici na daljinu), mogu učestvovati u Artisu. Indirektno 
učešće je takođe dozvoljeno ukoliko banke ovlaste neku dmgu banku da upravlja 
njihovim računom. Artis se bavi: 
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• nalozima za plaćanje od Centralne banke Austrije 

o operacije na novčanom tržištu, 
o gotovinski platni promet i 
o drugo, 

• plaćanjima drugim sistemima velike vrednosti, 

• međubankarskim plaćanjima koja proizilaze iz novčanog tržišta 

• međubankarskim plaćanjima koja proizilaze iz FX transakcija, 

• međubankarskim plaćanjima po nalogu klijenata u slučajevima kada se zahteva 
da saldiranje bude istog dana, 

• plaćanjima velike vrednosti. 

Kreditni rizik i rizik likvidnosti. Centralna banka Austrije ne preuzima nikakav rizik 
za neizvršena plaćanja jer se ona izvršavaju samo ukoliko tekući račun ima dovoljno 
pokriće ili ukoliko je učesnik u okviru dozvoljenog prekoračenja. Ukoliko učesnik ima 
manjak likvidnih sredstava, na njegov zahtev biće mu odobren traženi iznos dnevnog 
kredita, uz uslov da je obezbedio odgovarajući kolateral na depo računu. Limit dnevnog 
kredita za učesnike određuje se na osnovu vrednosti prethodno deponovanog kolaterala 
kod Centralne banke Austrije. Učesnik se obaveštava da li je traženo prekoračenje 
limita odobreno ili odbijeno, i u slučaju pozitivnog odgovora, odmah se inicira obrada 
plaćanja koja čekaju na računu učesnika. Dozvoljeno prekoračenje važi samo do kraja 
dana. U toku 2005. godine prosečan dnevni broj transakcija Artis-a iznosio je 15.417, sa 
prosečnom dnevnom vrednošću od EUR 49,15 milijardi. 

Platni promet u sistemu malih plaćanja. Većina plaćanja u ritejlu u Austriji izvršava 
se na bilateralnoj osnovi između kreditnih institucija. Platne transakcije se izvršavaju 
preko OeNB, najvećih austrijskih banaka ili banaka organizovanih unutar višeslojnih 
sektora pri centralnim instititucijama (štedionice, poljoprivredne kreditne zadruge ili 
Raiffeisen i industrijske kreditne zadruge ili Volksbanken). Međusektorska plaćanja se 
izvršavaju preko bilateralnih računa ili holdinga koji se vode kod trećih banaka. U 
višeslojnim sektorima centralne institucije su nadležne za ujednačavanje likvidnosti 
unutar i između sektora. Banke koje ne pripadaju nijednom višeslojnom sektoru drže 
bilateralne obračunske račune. Po pravilu, veće institucije predstavljaju institucije kod 
kojih se otvaraju računi, dok manje institucije vode evidencije. Računi se vode kao 
računi kreditora (na njima su međubankarski depoziti za upravljanje plaćanjima i 
likvidnošću). Step.AT nudi multilateralni kliring i istovremeno predstavlja altemativu 
postojećoj proceduri korespondentskog bankarskog poslovanja. 

Sistemi saldiranja hartija od vrednosti. Organizovana trgovina gotovinom i 
derivatima u Austriji obavlja se na Bečkoj berzi, jedinoj austrijskoj berzi akcija i jednoj 
od najstarijih berzi na svetu. Bečka berza je nezavisno tržište za austrijske hartije od 
vrednosti, kao i za hartije od vrednosti Centralne i Istočne Evrope i njihovih 
odgovarajućih derivata. CCP.Austria je centralni partner za sve berzanske transakcije i u 
vlasništvu je Bečke berze i austrijske Kontrolbanke (OeKB). Ona garantuje za sve 
transakcije na novčanom tržištu, kao i na tržištu derivata, i obezbeđuje kliring i druge 
usluge povezane sa kliringom za sve proizvode koji su predmet trgovine. Trgovina na 
berzi se obavlja preko Xetra kompjuterskog sistema za trgovinu. CCP.A je odgovoma 
za kliring i saldiranje na svih pet tržišnih segmenata Bečke berze. Austrijska 
Kontrolbank predstavlja klirinšku banku za CCP.A i istovremeno je odgovoma za 
saldiranje naloga. 
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Saldiranje. Oesterreichische Kontrolbank (OeKB) je istovremeno i austrijski centralni 
depozitar hartija od vrednosti. Sve hartije od vrednosti drže se u kolektivnim depoima 
što omogućava depozitarima da drže hartije od vrednosti različitih vlasnika u 
kolektivnom depou, bez potrebe da ih razvrstavaju i da stavljaju u depoe formirane za 
svakog vlasnika ponaosob. Svi vlasnici određene kategorije hartija od vrednosti su 
istovremeno i suvlasnici u odnosu na svoje holdinge. Centralni registar hartija od 
vrednosti (CRHoV) obezbeđuje široku paletu usluga deponovanja i saldiranja. Da bi 
neka institucija mogla da učestvuje u CRHoV, neophodno je da bude vlasnik računa 
hartija od vrednosti koji se vodi kod CRHoV, što se ugovara sa CRHoV. Ovo uključuje: 
kreditne institucije, priznate investicione firme, članove domaćih berzi, zvanične 
brokere na berzi hartija od vrednosti, strane Centralne registre i strane klirinške 
institucije za hartije od vrednosti. CRHoV takođe može da prihvati druga pravna i 
fizička lica, kao i partnerstva, kao nosioce računa hartija od vrednosti. CRHoV održava 
stalne veze sa jednim brojem evropskih centralnih registara uključujući Clearstream 
Banking (Frankfurt, Luksemburg), Euroclear Netherlands, SIS, Euroclear Bank i Monte 
Titoli. 

Sistemi plaćanja u Sjedinjenim Američkim Državama 

Udruženje klirinških kuća iz Njujorka organizovalo je CHIPS godine 1970, a postepeno 
su se uključivale i druge komercijalne banke, korporacije Edge Act, državne agencije 
Sjedinjenih Država i filijale stranih banaka, investicione kompanije prema članu XII i 
privatne banke [33], [234]. CHIPS je na početku koristio sistem sa poravnanjem na 
sledeći dan, a 1991. je prihvatio sistem sa poravnanjem na isti dan na kraju radnog dana. 
Međutim, sada se koristi sistem sa neprekidnim poravnanjem u realnom vremenu, u 
kojem se neprekidno vrši multilateralno umreženo poravnavanje. Svaka banka učesnica 
u obavezi je da položi na početku radnog dana i CHIPS-u iznos najmanje u visini 
„početne pozicije“ učesnika. Početne pozicije određuje predsednik CHIPS-a bar jednom 
mesečno prema obrascu fonnulisanom u klirinškoj kući. CHIPS-ovi računari prate sve 
poraste i opadanja početne pozicije učesnika i kretanja u toku dana i tako znaju 
„trenutnu poziciju“ svakog učesnika u datom momentu. Nalog plaćanja se ne odobrava 
ako bi doveo do toga da pozicija, bilo pošiljaoca, bilo primaoca padne ispod nule ili 
pređe dvostruki iznos njegove početne pozicije. 

Automatske klirinške kuće. Početkom sedamdesetih nagli porast obima obrade čekova i 
mogućnosti velikih novih računarskih sistema doveo je do pojave koncepta 
automatizovane klirinške kuće (. ACH - Automated Clearing House). Već 1974. 
osnovano je državno udruženje NACHA ( National Automated Clearing House 
Association ). Kroz njihove regionalne resurse banke Federalnih rezervi obezbeđuju 
resurse, opremu i osoblje za regionalne mreže ACH. Lokalne ACH kuće su povezane 
elektronski. 

ACH operateri su obično banke federalnih rezervi ali mogu da budu i privatne 
kompanije kao što je Američko udruženje klirinških kuća, Mreža elektronskog plaćanja, 
pridruženi član Njujorške automatske klirinške kuće ili VisaNet ACH servisa. ACH 
operateri primaju, uređuju i obrađuju elektronske stavke koje prime od drugih ACH 
operatera ili od depozitne finansijske institucije koja šalje (ODFI) i zatim obezbeđuje 
poravnanje između ODFI-ja i primajuće depozitne finansijske institucije (RDFI). ACH 
operateri čine ACH sistem na nivou države dostupnim svim depozitnim finansijskim 
institucijama. Kao fiskalni agenti SAD, banke federalnih rezervi pružaju usluge 
elektronskog plaćanja za programe Državne blagajne zasnovan na ACH-u za direktno 
usmeravanje federalnih periodičnih plaćanja kao što su socijalno osiguranje, veteranske 
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penzije i plate federalnih službenika. U okviru Ukaza o monetarnoj kontroli iz 1980. 
ACH operateri iz privatnog sektora pozvani su da konkurišu bankama federalnih 
rezervi. Ukaz je obezbedio da banke federalnih rezervi nisu više mogle da nude 
besplatne konkurentske usluge i bile su obavezne da naplate dovoljno da se pokriju 
troškovi usluge. „Faktor prilagođavanja privatnom sektoru“ uključuje se u cene obrade 
da bi se teren izravnao prema učesnicima koji žive od profita. Transakcije između ACH 
operatera u privatnom sektoru i onih iz banaka federalnih rezervi moraju biti usklađene 
sa operativnim uputstvima federalnih rezervi o rasporedu međuregionalnih depozita i 
rezervisanja. ACH operateri iz privatnog sektora međusobno razmenjuju transakcije 
prema rasporedu depozita i distribucije koji sami usklađuju. 

Nadređena organizacija. NACHA obezbeđuje nadzor i upravljanje najvećoj američkoj 
mreži elektronskog plaćanja. Što je najvažnije, NACHA kreira, vrši reviziju i održava 
pravila i smernice ACH operatera. On takođe razvija programe za povećanje obima 
ACH a ima i obrazovne servise za svoje članove i korisnike ACH sistema. Regionalne 
ACH kuće zadužene su za lokalna pravila i takođe pružaju obrazovanje i usluge koje 
omogućavaju povezivanje svih vrsta finansijskih institucija - komercijalnih banaka, 
štedionica i kreditnih zajednica. 

3.4.1 Platni sistemi u državama Zapadnog Balkana 

U nekadašnjoj Jugoslaviji Zavod za obračun i plaćanje - ZOP, u sastavu Narodne banke 
Jugoslavije, obavljao je poslove platnog prometa, evidencije i finansijske statistike, kao 
i poslove kontrole pravnih lica u Saveznoj Republici Jugoslaviji, za čije je obavljanje 
Narodna banka Jugoslavije, i u skladu sa propisima kojima je bio uređen način i 
postupak obavljanja platnog prometa dotadašnje Službe za platni promet, a do 
donošenja propisa i opštih akata, kojima je Narodna banka Jugoslavije uređivala 
obavljanje tih poslova [33], [234], 

Opis poslova које је obavljao nekadašnji Zavod za obračun i plaćanja - ZOP 

Poslovi platnog prometa: otvaranje, vođenje i ukidanje računa učesnika u platnom 
prometu; obračun izvršenih plaćanja; prenos novčanih sredstava između učesnika u 
platnom prometu; naplata, uplata i isplata sa računa; kontrola izvršenog platnog 
prometa, kao i drugi poslovi platnog prometa, u skladu sa propisima [33], [234]. 

Poslovi evidencije i finansijske statistike obuhvataju: vođenje jedinstvenog plana 
računa; vođenje plana računa za uplatu javnih prihoda i registra imalaca računa; 
evidentiranje stanja i promena stanja na računima, evidentiranje uključivanja sredstava 
depozita i novčanih tokova, kao i evidentiranje naplate i rasporeda javnih prihoda; 
poslove izveštavanja po evidencijama koje se vode u Zavodu. Zavod prikuplja, 
kontroliše, obrađuje i publikuje podatke iz godišnjih obračuna i izveštaja pravnih lica. 

Poslovi kontrole: Zavod obavlja kontrolu primene saveznih zakona i drugih propisa 
kojima se uređuje računovodstvo, platni promet u zemlji i isplata zarada zaposlenih kod 
pravnih lica i radnji koje su dužne da vode poslovne knjige, kao i kontrolu izmirivanja 
obaveza prema saveznom budžetu - do donošenja saveznog zakona kojim će se urediti 
ta kontrola. Zavod obavlja reviziju računovodstvenih iskaza pravnih lica i reviziju 
javnih rashoda, osim revizije banaka i drugih finansijskih organizacija, na način i do 
rokova koji su utvrđeni saveznim zakonima kojima se uređuje obavljanje tih poslova. 
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Pravni poslovi obuhvataju: izradu pojedinačnih akata u upravnom postupku i drugim 
postupcima, zastupanje po ovlašćenju guvemera, pred sudovima i dmgim državnim 
organima. 

Organizaciono-kadrovski i opšti poslovi obuhvataju: vođenje kadrovske evidencije 
radnika Zavoda; izradu pojedinačnih akata iz oblasti radnih i stambenih odnosa i zarada; 
pripremanje i sprovođenje konkursa - oglasa o prijemu radnika na rad u organizacione 
jedinice Zavoda; održavanje poslovnih zgrada i osnovnih sredstava; realizaciju 
ugovorenih nabavki; poslove obezbeđenja i zaštite na radu i dmge opšte poslove. 

Računovodstveno-finansijski poslovi obuhvataju vođenje poslovnih knjiga o 
sredstvima i izvorima sredstava Zavoda po organizacionim jedinicama, na nivou 
analitike računa za praćenje poslovanja koje te jedinice obavljaju u skladu sa Odlukom 
o analitičkom kontnom planu Narodne banke. 

Iz ZOP-a su tokom ustanovljavanja platnih sistema u nezavisnim državama koje su 
nastale posebno razvijani platni sistemi za velika plaćanja, mala plaćanja i sistemi za 
poravnanje hartija od vrednosti, koji su prikazani u nastavku rada: 

Bosna i Hercegovina 

Opšti okvir. Posebne karakteristike okmženja u BiH posledica su složene političke 
situacije, uticaja stranog faktora, decentralizovane funkcije centralne banke i 
neusaglašenosti donošenja zakonske regulative [33], [234]. Raspadom SFR Jugoslavije 
u BiH su stvorena tri platna sistema, od kojih je svaki imao monopol na bezgotovinsko 
plaćanje na teritoriji koju je pokrivao: ZPP u području sa bošnjačkim stanovništvom, 
ZAP u području sa hrvatskim stanovništvom u Federaciji i SPP u Republici Srpskoj. 
Predstavnici međunarodne zajednice u Madridu doneli su odluku 1998. godine o 
zatvaranju Zavoda za platni promet (ZPP) i formiranju posebnih klirinških kuća. Platni 
promet je podeljen posebno za Republiku Srpsku i Federaciju Bosne i Hercegovine sa 
zajedničkom Centralnom bankom, koja vrši poravnanje narednog dana. 

Opšti regulatorni okvir. Specifičnost organizacije u BiH ogleda se i u zakonskoj 
regulativi koja se odnosi na poslove platnog prometa. Platni sistem je jedinstven za celo 
područje BiH, a pošto su u pitanju dve države, regulativa je podvojena. Pravni osnov za 
funkcionisanje platnog prometa u BiH jeste Zakon o platnim transakcijama u Federaciji 
Bosne i Hercegovine, koji je donet u avgustu 2000. godine, a platni promet u RS 
sprovodi se prema odredbama Zakona o platnim transakcijama u Republici Srpskoj, koji 
je donet u decembru iste godine. Ta dva zakona su vrlo detaljno harmonizovana i među 
njima ne postoje bitne razlike, čime je omogućena suštinska integracija platnog prometa 
ovih entiteta. Oba zakona jasno definišu tipove platnih transakcija, učesnike u platnom 
prometu, načine izvršavanja naloga, odgovomosti, štete i restitucije i sve ostalo što je 
neophodno za funkcionisanje platnog sistema. 

Učesnici u sistemu. Najviši organ CB BiH je Upravno vijeće, koje je nadležno za 
utvrđivanje monetarne politike i kontrolu njenog sprovođenja, organizaciju i strategiju 
Centralne banke u skladu s ovlašćenjima utvrđenim zakonom. Centralna banka BiH ima 
Centralni ured, tri glavne jedinice i dve filijale. Centralni ured je u Sarajevu, a glavne 
jedinice su Glavna jedinica Sarajevo, Glavna banka Republike Srpske Banjaluka i 
Glavna jedinica Mostar. Filijale su Filijala Centralne banke u Brčkom i Filijala Glavne 
banke RS na Palama. Centralna banka BiH je centralni i ključni učesnik u radu platnog 
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sistema BiH. Sve transakcije sistema RTGS i žirokliring sistema prikupljaju se u 
operativnom centru Centralne banke, koja obavlja kliring i saldiranje tih platnih naloga, 
a zatim vraća informacije poslovnim bankama. U platnim transakcijama banka može 
vršiti radnje za klijenta ili korespondentsku banku koja se nalazi izvan Bosne i 
Hercegovine, u skladu sa važećim propisima. 

Gotovinska plaćanja. Od 1998. godine za gotovinska plaćanja u BiH kao nacionalna 
valuta koristi se konvertibilna marka. Oznaka valute je BAM, a šifra 977. Konvertibilna 
marka je odlukom CB BiH u fiksnom paritetu, koji je naveden u prethodnom odeljku, i 
svaka emitovana novčanica pokrivena je evrima. 

Sistem plaćanja velikih vrednosti. U BiH je organizovan RTGS - bruto sistem 
poravnanja u realnom vremenu, za transfer plaćanja velikih vrednosti. Ovaj sistem 
sadrži CAS - Central Accounting Svstem u kome su, u CB BiH, sredstva banaka koje 
učestvuju u platnim transakcijama i gde se vrši poravnanje platnih naloga. Sistem RTGS 
je skuplji od žirokliringa i trebalo bi da se koristi uglavnom za velika plaćanja [2], 
Sistem RTGS je veoma siguran, s obzirom na to da koristi sve prednosti SWIFT mreže, 
koja ima najviše standarde sigumosti, a sistem tehnički onemogućava poravnanje 
naloga za koje prethodno nisu obezbeđena sredstva. Takav nalog se neće izvršiti sve 
dok banka ne obezbedi dovoljna sredstva na računu. U ovom sistemu banke mogu slati 
plaćanja svakog radnog dana, u periodu od 8.00 do 16.00 časova. 

Platni sistemi malih vrednosti. Žirokliring (Gyro Clearing ) je sistem plaćanja malih 
vrednosti, do 20.000 KM. Funkcioniše po principu multilateralnog kliringa koji se 
odvija u tri ciklusa u toku radnog dana, 9.50 - I ciklus, 12.50 - II ciklus i 14.50 - III 
ciklus. U svim klirinškim ciklusima prethodno se objedinjuju nalozi koji stižu iz svih 
centara u BiH. Sva plaćanja između učesnika u kliringu poravnaju se i samo rezultat tog 
poravnanja, neto zaduženja ili odobrenja odlaze u sistem RTGS, gde je poravnanje 
konačno kada se ova salda prenesu sa računa banaka koje duguju na račune banaka koje 
potražuju. Žirokliring koristi SWIFT formate poruka, ali ne i SWIFT mrežu, kao sistem 
RTGS. Centralna banka BiH je, za potrebe žirokliringa, izgradila potpuno novu mrežu u 
BiH. Sve komercijalne banke, u zavisnosti od toga u kom delu BiH se nalaze, 
najkvalitetnijim telekomunikacionim linijama vezane su za potklirinške kuće u 
Banjaluci, Mostaru i Sarajevu, a nove na Žirokliring centar u CB BiH u Sarajevu. 

Sistem za kliring i saldiranje hartija od vrednosti. Kao što je već navedeno u delu 
disertacije koji se odnosi na zakonsku regulativu, kliring i saldiranje u BiH vrše dve 
institucije. To su Registar vrijednosnih papira u Federaciji BiH, sa sedištem u Sarajevu, 
dok u Banjaluci funkcioniše Centralni registar hartija od vrijednosti a.d. Banjaluka. 

Republika Makedonija 

Opšti okvir. U platnom sistemu koji je u Makedoniji funkcionisao pre refonne 
razlikovale su se dve grupe učesnika - fizička i pravna lica [33], [234]. Fizička lica su 
se u platni promet uključivala preko banaka, a pravna lica su imala zakonsku obavezu 
posedovanja jedinstvenog žiro računa u Zavodu za platni promet (ZPP). U oktobru 
1997. godine Narodna banka Republike Makedonije (NBRM) usvojila je odluku po 
kojoj se velika plaćanja (preko 5 miliona denara, a od aprila 1998. godine granica je 
preko 3 miliona denara) izvršavaju preko komercijalnih banaka. Ova mera je dovela do 
višeg stepena integracije bankarskog i privrednog sektora. Osim toga, bankama je bilo 
omogućeno da raspolažu infonnacijama na osnovu kojih su bile u stanju da obezbede 
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optimalnu likvidnost za podmirenje saldiranja u toku dana. Odluka je bila prvi korak 
refonne platnog sistema, koja je započeta 2001. godine. 

Opšti regulatorni okvir. Zakonska regulativa u oblasti nacionalnog platnog sistema 
Makedonije doneta je pre početka prelaska platnog prometa u banke da bi se izbegli 
problemi, kojih je bilo u iskustvu Bosne i Hercegovine, u kojoj je zakonska regulativa 
kasnila i izazvala je velike probleme. Osnovni zakon koji se primenjuje je Zakon o 
platnom prometu [150]. Prva verzija, koja je omogućila primenu novih odrednica u 
izmenjenom platnom sistemu, počela je da se primenjuje 1. jula 2001. godine. Prema 
tom zakonu, određeno je da su nosioci platnog prometa NBRM i banke koje imaju 
dozvolu da se bave platnim prometom. Uveden je obavezni bezgotovinski platni promet 
za sva preduzeća, a gotovina u blagajnama preduzeća ograničena je blagajničkim 
maksimumom. Ograničeno je i plaćanje u gotovini. Ovaj zakon je predstavljao veliko 
unapređenje za Makedoniju i omogućio joj je da reformiše platni sistem po ugledu na 
razvijene evropske zemlje. Poslednja verzija zakona usvojena je 2007. godine, a počela 
je da se primenjuje 1. januara 2008. godine. Uvedene su vrlo značajne odrednice vezane 
za izdavanje elektronskog novca i elektronskog plaćanja. 

Učesnici u sistemu. Narodna banka Republike Makedonije je vlasnik, operater i 
kontrolor platnih sistema. Na osnovu tih funkcija, NBRM otvara račune institucija 
odgovomih za obavljanje poslova platnog prometa. U tu svrhu, institucija odgovoma za 
sprovođenje platnog prometa podnosi zahtev za otvaranje računa, uz neophodne 
dokumente, kao i spisak ovlašćenih potpisnika i ugovor o otvaranju naloga. Svi 
postojeći računi stoje na raspolaganju učesnicima elektronskim putem u sistemu MIPS. 
Osim toga, učesnik može i da zatvori račun u NBRM podnošenjem zahteva za 
zatvaranje računa, a račun učesnika može biti zatvoren i na osnovu sudske odluke ili po 
nalogu nadležnog organa. Dmga velika gmpa učesnika su poslovne banke, koje u 
Makedoniji, u okvim platnog sistema, pokrivaju sve aktivnosti koje su neophodne da bi 
platni promet mogao da se obavlja bez zastoja. Otvaraju i održavaju račune iizičkih i 
pravnih lica, primaju i prosleđuju platne instmkcije u samoj banci, u međubankarskom 
platnom prometu i međunarodnom platnom prometu. Obezbeđuju i funkcionisanje 
plaćanja po osnovu transakcija elektronskih platnih kartica [142]. 

Gotovinska plaćanja. Denar je zvanična valuta Republike Makedonije. Oznaka denara 
je MKD, a šifra 4217. Narodna banka Republike Makedonije ima ekskluzivno pravo na 
štampanje i izdavanje gotovinskih novčanica u Makedoniji. 

Sistem plaćanja velikih vrednosti. U Makedoniji za promet platnih naloga velikih 
vrednosti organizovan je Makedonski interbankarski platni sistem - MIPS, koji po 
svojim karakteristikama spada u bmto sistem obračuna u realnom vremenu (RTGS). 
Operator i vlasnik MIPS sistema je NBRM. Cilj sistema je da obezbedi nesmetano 
funkcionisanje platnog prometa, kao i realizaciju svih operacija koje su inicirane od 
učesnika. Transakcije se obavljaju u skladu sa Operativnim pravilima sistema MIPS. 

Platni sistemi malih vrednosti. Vlasnik i operator platnog sistema za obračun malih 
vrednosti je klirinška kuća Klirinški interbankarski sistemi a.d. Skoplje. Nju su 2001. 
godine osnovale banke, saglasno Zakonu o platnom prometu, sa ciljem obavljanja 
kliringa i saldiranja plaćanja malih vrednosti na multilateralnoj neto osnovi. Učesnici u 
kliringu su banke registrovane za obavljanje domaćeg platnog prometa. Granični iznos 
koji se može procesirati putem kliringa je 1.000.000 denara. Klirinška kuća funkcioniše 
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u skladu sa pozitivnom zakonskom regulativom u oblasti platnog prometa Makedonije, 
uzimajući u obzir BIS pravila i preporuke. Sistem koji funkcioniše u okviru klirinške 
kuće poštuje Pravila poslovanja i obuhvata sledeće podsisteme: kliring malih 
međubankarskih plaćanja (KIBS-kliring), jedinstveni registar transakcionih računa 
(Erts-KIBS), informacije o blokiranim računima (KIBS-blokada), izdavanje sertifikata 
(KIBS-IS), informativni servis (KIBS-info). 

Sistem za kliring i saldiranje hartija od vrednosti. Institucija koja je u Makedoniji 
zadužena za kliring i saldiranje hartija od vrednosti je Centralni depozitar za hartije od 
vrednosti a.d. Skoplje (Централен депозитар за хартии од вредност а.д. Скопје). U 
skladu sa članom 172 Zakona o hartijama od vrednosti Republike Makedonije i 
Odlukom br. 07-167/1, u februaru 2001. godine ZPP je dobio ovlašćenje Vlade 
Makedonije da sprovede mere i aktivnosti za osnivanje i implementaciju Registra hartija 
od vrednosti. Osnovni cilj Centralnog registra bilo je uspostavljanje registra svih hartija 
od vrednosti (akcija i obveznica) emitovanih u Republici Makedoniji. Osnivanjem 
registra predviđeno je da budu zadovoljeni interesi: vlasnika hartija od vrednosti, stranih 
investitora, trećih strana u transakcijama, emitenata, brokera, Makedonske berze akcija, 
drugih autorizovanih institucija, ali i formiranje depoa hartija od vrednosti. 

Republika Hrvatska 

Opšti okvir. Početkom primene novog Zakona o platnom prometu u Hrvatskoj, u aprilu 
2002. godine ostvaren je i poslednji korak u sprovođenju reforme hrvatskog platnog 
sistema, čime je obezbeđena nova infrastruktura [33], [234]. Platni sistem u Hrvatskoj 
postavljen je na tri nivoa. Prvi nivo se obavlja u okviru pojedinačne poslovne banke, 
koja vrši plaćanje i saldiranje između svojih komitenata - deponenata. Drugi nivo je 
obračun u Nacionalnom klirinškom sustavu (NKS) preko koga se banke međusobno 
saldiraju za plaćanja svojih komitenata ako su deponenti druge banke. Direktni učesnici 
u obračunu preko sistema NKS jesu banke i štedionice. Učesnik u sistemu NKS je i 
Hrvatska narodna banka (HNB), a učesnik može biti i institucija koja posreduje u 
obavljanju poslova platnog prometa, institucija koja obavlja poslove platnog prometa u 
ime i za račun banke/štedionice i pravno lice koje, na osnovu posebnog ovlašćenja 
direktnog učesnika, dostavlja naloge za platne transakcije u NKS, radi obračuna. Treći 
nivo je Hrvatski sustav velikih plaćanja (HSVP). 

Institueionalni aspekti. Centralna institucija u hrvatskom platnom prometu je Hrvatska 
narodna banka. Ona je bila ključna u sprovođenju refonne platnog prometa, u periodu 
od januara do aprila 2002. godine. Tada je platni promet decentralizovan i poslovi u 
ovom domenu preneti su sa centralizovane ustanove na poslovne banke. Hrvatska 
narodna banka je u tom periodu formirala Jedinstveni registar računa poslovnih 
subjekata. Od 2002. godine Jedinstvenim registrom računa poslovnih subjekata 
operativno upravlja Financijska agencija. 

Opšti regulatorni okvir. Regulativa i nadzor nad platnim sistemom Hrvatske u 
nadležnosti je HNB. Ona funkcioniše na osnovu Zakona o Hrvatskoj narodnoj banci, 
kojim se regulišu najvažnija pitanja i domen ove institucije (položaj, poslovi, vlasnički 
status, ovlašćenja i organizacija HNB, kao i odnos HNB sa Republikom Hrvatskom, 
bankama i međunarodnim institucijama i organizacijama). Nosioci poslova platnog 
prometa su HNB i banke. Nedepozitne institucije mogu, na osnovu ugovora, poslove 
platnog prometa da obavljaju samo u ime i za račun depozitnih institucija. 
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Gotovinska plaćanja. Kuna je zvanična valuta koja se koristi za gotovinska plaćanja u 
Hrvatskoj. Oznaka valute je HRK, a šifra 191. Hrvatska narodna banka izdaje kovani i 
papirni novac, a gotovinska plaćanja predstavljaju značajan udeo u ukupnim plaćanjima. 

Sistem plaćanja velikih vrednosti. Hrvatska narodna banka je vlasnik i kontrolor 
Hrvatskog sustava velikih plaćanja (HSVP). Sistem HSVP je proizvod kompanije 
LogicaCMG iz Londona i započeo je sa radom 6. aprila 1999. godine. 

Platni sistemi malih vrednosti. Nacionalni klirinški sustav (NKS) jeste platni sistem 
malih vrednosti čiji je vlasnik i operator FINA. Počeo je sa radom 5. februara 2001. 
godine. Sistem NKS je namenjen obračunu naloga za prenos između učesnika na neto 
multilateralnoj šemi. Učesnici NKS-a su banke, HNB i treće strane. Posredni učesnici 
sistema NKS su banke i druge finansijske institucije koje, na osnovu posebnih propisa, 
koje donosi HNB, izvršavaju saldiranje međubankarskih platnih transakcija preko druge 
banke. 

Sistem za kliring i saldiranje hartija od vrednosti. Središnje klirinško depozitamo 
društvo d.d. (SKDD) upravlja centralnim depoom dematerijalizovanih hartija od 
vrednosti, upravlja sistemom kliringa i saldiranja transakcija hartijama od vrednosti 
sklopljenih na tržištu berze i na multilateralnoj trgovinskoj platfonni (MTP) ili izvan 
tržišta berze i MTP-a (OTC transakcije), i određuje jedinstvene identifikacione oznake 
dematerijalizovanih hartija od vrednosti (ISIN i CFI oznake). 

Republika Crna Gora 

Opšti okvir. Svesna značaja platnog sistema, Centralna banka Cme Gore (CBCG) 
otpočela je, odmah po osnivanju samostalne države, 2001. godine, sa reformom tog 
sistema [33], [234]. U prvoj fazi izrađena je sveobuhvatna strategija razvoja platnog 
sistema u Cmoj Gori. U „Analizi finansijskog tržišta 2007. godine“ istaknuto je da je 
reforma sprovedena fazno, imajući u vidu vrlo specifičan i funkcionalno kompleksan 
platni sistem, koji je nasleđen od bivše SFRJ i SRJ. Njeni prioriteti su: 
demonopolizacija poslova u platnom prometu, u smislu da poslovne banke svojim 
klijentima ubuduće pmžaju sve usluge u platnom prometu i izgradnja potpuno novog, 
modernog platnog sistema uz maksimalno uvažavanje svih relevantnih međunarodnih 
prepomka i bankarskih standarda, kao i specifičnih potreba u zemlji. Sve aktivnosti 
sprovedene su u koordinaciji sa poslovnim bankama, državnim organima i 
organizacijama i drugim relevantnim subjektima, i uz intenzivnu konsultantsku pomoć 
pojedinih međunarodnih organizacija i centralnih banaka zemalja iz okmženja. 

Opšti regulatorni okvir. Ključni regulatorni okvir u oblasti platnog sistema u Cmoj 
Gori jeste Zakon o platnom prometu u zemlji, koji je donet u oktobm 2008. godine. Cilj 
tog zakona je unapređenje platnog prometa u zemlji, dalje usklađivanje regulative sa 
suštinskim principima za sistemski važne platne sisteme, Komitetom za platne i 
obračunske sisteme Međunarodne banke za obračun, kao i regulativom EU. 

Učesnici u sistemu. Prema Zakonu o platnom prometu u zemlji, učesnici u platnom 
sistemu mogu biti: Centralna banka, banke i filijale stranih banaka, državni organi i 
nosioci javnih ovlašćenja, centralne banke ostalih zemalja, ECB, Centralna depozitarna 
agencija i ovlašćeni učesnici na tržištu hartija od vrednosti. 
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Gotovinska plaćanja. Cma Gora ima specifičnu situaciju sa valutom u odnosu na 
ostale zemlje Zapadnog Balkana. Zvanično sredstvo plaćanja u Cmoj Gori je evro. 
Uveden je na osnovu Zakona o Centralnoj banci, kao zamena za nemačku marku, koja 
je 2000. godine zamenila dinar. Odnos te dve valute, koji su utvrdile EU, centralne 
banke zemalja evrozone i ECB jeste 1 EUR= 1,95583 DEM. Taj kurs je fiksni i ne 
menja se, kao ni kursevi ostalih bivših valuta zemalja evrozone. 

Sistem plaćanja velikih vrednosti. Platni sistem velikih vrednosti u Crnoj Gori 
organizovan je kao i u ostalim zemljama Zapadnog Balkana po principu bmto obračuna 
u realnom vremenu - RTGS. Učesnici u sistemu RTGS su CBCG, banke koje obavljaju 
poslove platnog prometa u zemlji i drugi subjekti čiji se računi, u skladu sa zakonom, 
vodekodCBCG. 

Platni sistemi malih vrednosti. Sistem DNS organizuje se u okvim CBCG i služi za 
procesiranje malih plaćanja, po multilateralnom neto principu sa odloženim vremenom 
obračuna. Učesnici u DNS sistemu su CBCG i banke koje obavljaju poslove platnog 
prometa u zemlji. 

Sistem za kliring i saldiranje hartija od vrednosti. Na tržištu kapitala u Crnoj Gori 
funkcionisale su dve berze: Montenegroberza a.d. i Nova berza hartija od vrijednosti 
Crne Gore a.d. Montenegroberza je osnovana u junu 1993. godine, na osnovu Zakona o 
tržištu novca i tržištu kapitala. Od septembra 2006. godine, Montenegroberza je u 
potpunosti u privatnom vlasništvu. Vlada Cme Gore je, aukcijskom prodajom na berzi, 
prodala svoj udeo od 5% u Montenergoberzi. Dve cmogorske berze su spojene 
pripajanjem - NEX Montenegro je pripojen Montenegroberzi, 31. decembra 2010. 
godine. 

3.4.2 Platni sistemi u Srbiji 

Operator platnog sistema može biti: pravno lice koje upravlja radom platnog sistema, 
Narodna banka Srbije, banka sa sedištem u RS, platna institucija sa sedištem u RS, 
institucija elektronskog novca sa sedištem u RS, drugo pravno lice u RS osnovano kao 
a.d ili d.o.o, UBS ili drugi pmžaoci platnih usluga sa sedištem u RS, kreditna institucije 
iz države članice ili iz treće države preko svog ogranka, drugo pravno lice sa sedištem u 
državi članici preko svog ogranka [33], [234]. Poslovi platnog sistema su izvršavanje 
naloga za prenos, kliring (može uključiti i netiranje), netiranje (multilateralna ili 
bilateralna neto pozicija za poravnanje) i poravnanje (izmirenje novčane obaveze, 
odnosno namirenje potraživanja prenosom novčanih sredstava preko računa koji se 
koriste za poravnanje. 

Da bi pravno lice postalo operater platnog sistema, mora da priloži NBS pravila rada 
koji treba da sadrže: poslovno ime i sedište operatora i agenta za poravnanje, uslove za 
učešće i način učešća u platnom sistemu, način dostavljanja i provere naloga za prenos, 
način obavljanja kliringa i/ili poravnanja, prava i obaveze učesnika u platnom sistemu i 
operatora u vezi sa upravljanjem rizicima u platnom sistemu, radni dan i dnevni 
terminski plan rada platnog sistema, uslove i način prestanka učešća u platnom sistemu. 

Pravila rada platnog sistema koji je utvrđen kao bitan sadrže i momenat neopozivosti i 
momenat ulaska naloga za prenos u platni sistem. Pravilima rada ne smeju se ograničiti 
učešće u drugim platnim sistemima, diskriminatomo uređivati prava i obaveze učesnika, 
niti ograničavati učešće koje se zasniva na pravnom statusu učesnika u platnom sistemu 
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ili korisnika platnih usluga. Ne primenjuje se na: „sistemski važne“ platne sisteme i 
platni sistem čiji su učesnici isključivo pružaoci platnih usluga koji čine grupu društava 
povezanih udelom u kapitalu u kojoj jedno od tih društava ima kontrolno učešće nad 
drugim društvima u grupi. Narodna banka Srbije operatoru izdaje dozvolu Narodne 
banke Srbije, osim za rad platnog sistema čiji je operator NBS. 

Dužnosti operatora platnog sistema su: održavanje tehničkih, organizacionih, 
kadrovskih i drugih uslova utvrđenih ovim zakonom i drugim propisima, sistem 
upravljanja i sistem unutrašnjih kontrola, upravljanje rizicima u platnom sistemu. 
Operator je dužan da podnese zahtev za davanje saglasnosti za izmene i dopune 
elemenata pravila rada platnog sistema. NBS bliže propisuje sistem upravljanja i sistem 
unutrašnjih kontrola, kao i minimalne zahteve za upravljanje rizicima u platnom 
sistemu. Operator je dužan da o nameri da poveri obavljanje pojedinih operativnih 
poslova u vezi s radom platnog sistema drugog lica obavesti NBS. Operator mora 
obezbediti: da se ne umanjuju obaveze i odgovomosti operatora prema učesnicima, da 
se ne dovodi u pitanje usklađenost rada platnog sistema sa pravilima za rad i odredbama 
ovog zakona, da se ne namšava mogućnost obavljanja nadgledanja od strane NBS. 
Operator je dužan da čuva podatke o izvršenim nalozima za prenos i dmgu 
dokumentaciju nastalu u vezi sa uredbom platnog sistema, da u svojim poslovnim 
knjigama odvojeno evidentira poslovne promene koje se odnose na prihode ostvarene u 
vezi sa upravljanjem platnim sistemom, na pojedinačne finansijske izveštaje za 
prethodnu godinu, sa izveštajem spoljnog revizora dostavi NBS, da na svojoj Internet 
prezentaciji objavljuje i redovno ažurira osnovne informacije i podatke o platnom 
sistemu čiji je operator, da dostavlja izveštaje koji se odnose na upravljanje platnim 
sistemom. 

3.4.2.1 Zakonska regulativa za platne sisteme u Srbiji 

Zakoni koji regulišu procese platnih sistema u Republici Srbiji su sledeći [128]: 

• Zakon o Narodnoj banci Srbije, [151], [152] prečišćeni tekst sačinjen na 
osnovu teksta Zakona o Narodnoj banci Srbije („Službeni glasnik RS“, br. 
72/2003) i njegovih izmena i dopuna objavljenih u „Službenom glasniku RS“, 
br, 55/2004, 85/2005 - dr.zakon, 44/2010 i 76/2012 

• Zakon o izmenama i dopunama Zakona o Narodnoj banci Srbije, „Službeni 
glasnik RS“, br. 76/2012 

• Zakon o Narodnoj banci Srbije, prečišćeni tekst sačinjen na osnovu teksta 
Zakona o Narodnoj banci Srbije („Službeni glasnik RS“, br. 72/2003) i njegovih 
izmena i dopuna objavljenih u „Službenom glasniku RS“, br, 55/2004, 85/2005 
- dr.zakon i 44/2010 

• Zakon o bankama, [148] prečišćeni tekst sačinjen na osnovu teksta Zakona o 
bankama („Službeni glasnik RS“, br. 107/2005) i njegovih izmena i dopuna 
objavljenih u „Službenom glasniku RS“, br. 91/2010 

• Zakon o platnom prometu, prečišćeni tekst sačinjen na osnovu teksta Zakona o 
platnom prometu („Službeni list SRJ“, br. 3/2002) i njegovih izmena i dopuna 
objavljenih u „Službenom listu SRJ“, br. 5/2003 i „Službenom glasniku RS”, br. 
43/2004, 62/2006 i 31/2011 

Podzakonski akti se sastoje od odluka, pravila i uputstava [128]: 
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• Odluka o obavljanju kliringa i obračuna direktnih zaduženja po osnovu ovlašćenja, 
„Službeni glasnik RS“, br. 6/2010 

• Odluka o opštim pravilima za obavljanje direktnih zaduženja po osnovu ovlašćenja, 
„Službeni glasnik RS“, br. 6/2010, /ispravka 12/2010/ 

• Odluka o međubankarskom kliringu plaćanja u devizama, „Službeni glasnik RS“, br. 
31/2007,93/2007 

• Odluka o načinu obavljanja platnog prometa preko novčanog računa centralnog registra, 
depoa i kliringa hartija od vrednosti, „Službeni glasnik RS“, br. 89/2011 

• Odluka o obračunu i kliringu i o funkcionisanju obračunskih računa banaka kod 
Narodne banke Srbije, „Službeni glasnik RS“, 57/2004 

• Odluka o uslovima i načinu otvaranja, vođenja i gašenja računa kod banke, „Službeni 
glasnik RS“ br. 33/2005, 25/2009 

• Odluka o načinu nadgledanja platnih klirinških i obračunskih sistema, „Službeni glasnik 
RS“ br. 46/2009 

• Odluka o obliku, sadržini i načinu korišćenja jedinstvenih instrumenata platnog 
prometa, „Službeni glasnikRS" br.57/2004, 82/2004 

o Prilog 1 

■ Nalog za uplatu 

■ Nalog za isplatu 

■ Nalog za naplatu 

■ Nalog za prenos 
o Prilog 2 

o Prilog 2a 

• Odluka o bližim uslovima i načinu davanja i oduzimanja ha nk ama licence za obavljanje 
platnog prometa, „Službeni glasnik RS“ br.57/2004, 33/2005 

• Odluka o elektronskom načinu obavljanja platnog prometa, „Službeni glasnik RS“ br. 
57/2004 

• Odluka o jedinstvenoj strukturi za identifikaciju i klasifikaciju računa i o planu računa 
za obavljanje platnog prometa kod banke, „Službeni glasnik RS“ br. 57/2004 

• Odluka o određivanju poslova koje može da obavlja agent i uslovima za obavljanje tih 
poslova, „Službeni glasnik RS“ br. 57/2004, 33/2005 

• Odluku o vrsti podataka koje banke dostavljaju Narodnoj banci Srbije i o načinu i 
rokovima dostavljanja tih podataka, „Službeni glasnik RS“, br. 81/2010 

• Odluka o određivanju jedinstvenih identifikacionih brojeva banaka za obavljanje 
platnog prometa 

• Odluka o načinu vršenja kontrole platnog prometa kod banaka, „Službeni glasnik RS“ 
br. 57/2004 

• Odluka o obavljanju međubankarskog obračuna čekova po tekućim računima građana, 
„Službeni glasnik RS“ br. 72/2004 

• Odluka o obavljanju obračuna i poravnanja platnih kartica, „Službeni glasnik RS“ br. 
4/2009 

• Uputstvo o načinu i rokovima dostavljanja podataka banaka o izvršenom platnom 
prometu 

• Uputstvo za realizaciju naloga za međubankarska plaćanja u slučaju da učesnik RTGS i 
kliring sistema NBS nije u mogućnosti da realizuje plaćanja usled tehničkih problema 

• Uputstvo o načinu dostavljanja podataka za vođenje jedinstvenog registra računa 

• Uputstvo za dostavljanje Narodnoj banci Srbije podataka o poslovanju banaka s platnim 
karticama 

• Uputstvo o postupanju sa menicama izdatim do 31. decembra 2002. godine, „Službeni 
glasnik RS“ br. 114/2005 

• Prilog 1 (spisak filijala i ekspozitura Narodne banke Srbije u kojima postoje odseci za 
prinudnu naplatu) 
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• Instrukcije bankama za postupanje po reklamacijama u vezi sa međuha nk arskim 
plaćanjima 

• Operativna pravila za kliring međunarodnih plaćanja 

• Operativna pravila za kliring (neto obračun) 

• Operativna pravila za obračun u realnom vremenu po bruto principu 

• Operativna pravila za međuha nk arski kliring plaćanja u devizama 

• Uputstvo o formatu i nameni poruka za razmenu podataka u obavljanju poslova platnog 
prometa 

• Uputstvo za sprovođenje odluke o elektronskom načinu obavljanja platnog prometa 

3.4.2.2 Narodna banka Srbije kao operator platnih sistema 

Narodna banka Srbije [128], [33], [234] je operator tri platna sistema: RTGS sistema, 
kliring sistema i sistema međubankarskog i međunarodnog kliringa plaćanja u 
devizama. RTGS sistem (obračun u realnom vremenu po bruto principu) podrazumeva 
prijem i izvršavanje pojedinačnih naloga za plaćanje banaka u najkraćem mogućem 
vremenu od momenta njihovog prijema - i to do visine pokrića na računu. U RTGS 
sistemu mogu se izvršavati svi nalozi za plaćanje, s tim što se obavezno izvršavaju 
nalozi za plaćanje iznos većih od 250.000 dinara („velika plaćanja“), što je utvrđeno 
operativnim pravilima za RTGS sistem i kliring. Pod kliringom, tj. neto obračunom, 
podrazumeva se prijem pojedinačnih naloga za plaćanje, ili grupa naloga za plaćanje, uz 
koje se dostavlja specifikacija pojedinačnih naloga radi obračuna multilateralnih neto 
iznosa na obračunskim računima. Nakon toga, za svakog učesnika u kliringu utvrđuje se 
neto pozicija, čije se poravnanje vrši preko njegovog žiro računa. Plaćanja u kliringu 
(„mala plaćanja”) jesu nalozi čiji je iznos do 250.000 dinara. Plaćanja u kliringu 
izvršavaju se u procesu neto poravnanja u tri klirinška ciklusa svakog radnog dana (u 
10.30, 12.30 i 14.45 časova). Učesnici u RTGS sistemu i u kliring sistemu Narodne 
banke Srbije povezani su u jedinstvenu celinu, u kojoj se platne transakcije razmenjuju 
porukama, zasnovanim na SWIFT standardu, kroz privatnu komunikacionu mrežu 
Narodne banke Srbije. Sistern obezbeđuje primenu DVP (istovremeni prenos hartija od 
vrednosti i novčanih sredstava) principa u obračunu hartija od vrednosti. Učesnici u 
RTGS i kliring sistemu su Narodna banka Srbije, banke, Republika Srbija - 
Ministarstvo finansija, Centralni registar, depo i kliring hartija od vrednosti i Udruženje 
banaka Srbije. Radno vreme RTGS i kliring sistema utvrđeno je Dnevnim terminskim 
planom. Sistem izvršava transakcije učesnika u toku radnog dana od 9.00 do 18.00 
časova. 

Pravna lica i fizička lica koja obavljaju delatnost dužna su da za plaćanje u dinarima 
otvore tekući račun u banci, da vode sredstva na tom računu i vrše plaćanja preko tog 
računa, u skladu sa Zakonom o platnom prometu i ugovorom o otvaranju i vođenju tog 
računa zaključenim s bankom. Fizička lica koja ne obavljaju delatnost mogu imati kod 
banke račune za plaćanje u dinarima. Pravna i fizička lica mogu imati više od jednog 
računa u jednoj banci i račune u više banaka. 

3.4.2.3 Platni sistemi malih plaćanja u Srbiji 

Sistemi malih plaćanja u Republici Srbiji koji su osnovani na osnovu Zakona o platnom 
prometu i propisima donetim na osnovu tog Zakona su: Kliring sistem Narodne banke 
Srbije, DinaCard sistem i Sistem za međubankarski kliring čekova, Sistem za 
međubankarski kliring direktnih zaduženja [33], [234]. 

Kliring sistem Narodne banke Srbije je sistem za razmenu i obradu pojedinačnih 
naloga za plaćanje ili grupa naloga za plaćanje učesnika u platnom sistemu radi 
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obračuna multilateralnih neto iznosa za poravnanje. Operator kliring sistema je Narodna 
banka Srbije, a poravnanje multilateralnih neto pozicija obavlja se u RTGS sistemu. 
Učesnici u kliring sistemu mogu biti: Narodna banka Srbije, banke i Republika Srbija - 
ministarstvo nadležno za poslove linansija. 

DinaCard sistem - sistem za procesiranje i obradu potraživanja učesnika po osnovu 
korišćenja nacionalne platne kartice - DinaCard, radi obračuna multilateralnih neto 
iznosa za poravnanje. Operator DinaCard sistema je Narodna banka Srbije, odnosno, 
organizacioni deo Narodne banke Srbije koji je nadležan za kliring po karticama - 
Nacionalni centar za platne kartice, a poravnanje multilateralnih neto pozicija obavlja se 
u RTGS sistemu. Učesnici u DinaCard sistemu mogu biti: banke koje izdaju DinaCard 
kartice i banke preko kojih nastaje potraživanje po osnovu korišćenja. DinaCard kartica, 
a koje su vlasnici mreža za prijem kartica. 

Sistem za međubankarski kliring čekova je sistem za procesiranje i obradu 
potraživanja učesnika po osnovu čekova po tekućim računima građana. Operator 
sistema za međubankarski kliring čekova je Udruženje banaka Srbije, a poravnanje 
multilateralnih neto pozicija obavlja se u RTGS sistemu. Učesnici u sistemu mogu biti: 
banke i Republika Srbija - ministarstvo nadležno za poslove finansija, koji sa 
Udruženjem banaka Srbije potpisuju Sporazum o obavljanju međusobnih usluga. 

Sistem za međubankarski kliring direktnih zaduženja je sistem za procesiranje i 
obradu transakcija po osnovu direktnih zaduženja radi izračunavanja multilateralnih 
neto iznosa za poravnanje. Operator sistema za međubankarski kliring direktnih 
zaduženja je Udruženje banaka Srbije, a poravnanje multilateralnih neto pozicija 
obavlja se u RTGS sistemu. Učesnici u sistemu mogu biti: banke i Republika Srbija - 
ministarstvo nadležno za poslove finansija, koji sa Udruženjem banaka Srbije potpisuju 
ugovor o obavljanju kliringa i obračuna direktnih zaduženja. 

Radi efikasnije primene Odluke o načinu nadgledanja platnih klirinških i obračunskih 
sistema i Politike nadgledanja, Narodna banka Srbije je na bazi utvrđenih Kriterijuma za 
klasifikaciju platnih sistema malih plaćanja koji funkcionišu u Republici Srbiji i 
podataka za 2009. godinu procenila značaj sistema malih plaćanja i klasifikovala 
Kliring sistem Narodne banke Srbije kao sistemski značajan platni sistem, a kao 
značajne platne sisteme DinaCard sistem i sistem za međubankarski kliring čekova, 
prikazano utabeli 7, za period 01.01. - 31.12.2009. godine. 


rbr 

Indikator 

Kliring sistem NBS 

DinaCard sistem 

Međubankarski 
kliring čekova 

1 . 

Tržišno učešće 

87,59 %; 

6,59 % 

5,82 % 

2. 

Učešće u RTGS-u 

1,69%; 

0,13% 

0,11% 

3. 

Prosečna dnevna 
vrednost u dinarima 

2.021.137.069,39 

152.055.598,31 

134.411.151,44 

4. 

Koncentracioni racio 

58,41%; 

68,51% 

80,46 

5. 

Neting racio 

66,27%; 

74,53% 

45,31% 

6. 

Najveća negativna neto 
pozicija u dinarima 

115.538.272.362,52 

14.956.220.054,29 

11.966.440.053,66 


Tabela 7. Kvantitativni indikatori za sisteme malih plaćanja u RS 
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3.4.2.4 Nadgledanje platnih sistema u Srbiji 

Narodna banka Srbije daje dozvolu i vodi evidenciju platnih sistema koji imaju dozvolu 
za rad, kao i platnih sistema pod upravom Narodne banke Srbije [128], [141]. Narodna 
banka Srbije vrši i nadzor nad obavljanjem poslova platnih sistema. Predmet nadzora je 
provera usklađenosti poslovanja platnog sistema (sigumost i ciikasnost) sa zakonom o 
platnim uslugama i podzakonskim aktima donetim na osnovu tog zakona. Nadzor se 
vrši nad operatorom u delu njegovog poslovanja koji se odnosi na upravljanje radom 
platnog sistema. Način vršenja nadzora može biti posredan ili neposredan. Na osnovu 
nadzora propisuju se odgovarajuće mere u postupku nadzora koje mogu biti: upućivanje 
preporuke, upućivanje pismene opomene, upućivanje nalogodavnog pisma, izricanje 
naloga i mera za otklanjanje utvrđenih nepravilnosti, oduzimanje dozvole za rad platnog 
sistema. Narodna banka Srbije može da odlučuje o meri koju preduzima prema subjektu 
nadzora na osnovu diskrecione ocene. 

Nadgledanje platnih sistema je funkcija centralne banke u okvim koje se ciljevi 
sigumosti i efikasnosti promovišu praćenjem postojećih i planiranih sistema, procenom 
tih sistema i po potrebi, iniciranjem promena u njima. Centralne banke su posebno 
zainteresovane za sigumo i efikasno funkcionisanje platnih sistema zbog ostvarivanja 
njihovih osnovnih funkcija - obezbeđivanja poverenja u nacionalnu valutu i očuvanja 
finansijske stabilnosti. Obavljanje funkcije nadgledanja od strane centralne banke 
usmereno je na određeni sistem, a ne na individualne učesnike u sistemu. 
Transparentnost centralne banke u vezi s obavljanjem funkcije nadgledanja je od 
izuzetnog značaja za operatore sistema, kako bi razumeli i pratili poslovne zahteve i 
standarde sa kojima se očekuje da budu usaglašeni. Pored toga, centralne banke, kroz 
transparentnost, demonstriraju adekvatan stepen doslednosti u obavljanju nadgledanja i 
pmžaju osnovu za ocenu njegove uspešnosti. 

Radi boljeg razumevanja i efikasnije primene odluke kojom se uređuje način 
nadgledanja platnih klirinških i obračunskih sistema, a u saglasnosti s principima za 
uspešno nadgledanje za koje se zalaže Banka za međunarodna poravnanja (Bank for 
International Settlement - BIS ), Narodna banka Srbije definiše Politiku nadgledanja 
platnih sistema. Politikom nadgledanja platnih sistema bliže se utvrđuju ciljevi i 
aktivnosti nadgledanja koje obavlja Narodna banka Srbije radi unapređenja platnih 
sistema i obezbeđivanja nesmetanog funkcionisanja platnog prometa u zemlji. Osnovni 
ciljevi nadgledanja su sigurnost i efikasnost platnih sistema i instrumenata plaćanja, 
kojima se iniciraju transakcije plaćanja koje se izvršavaju u platnim sistemima. 
Sigumost označava limitiranje rizika koji se mogu pojaviti u platnom sistemu i koji 
mogu ugroziti ili negativno uticati na adekvatno i kontinuirano funkcionisanje platnog 
sistema i finansijsku stabilnost zemlje. Efikasnost podrazumeva brzo i ekonomično 
obavljanje operacija u platnom sistemu, kao i nivo usluga koji je ekonomski isplativ za 
učesnike sistema i njihove klijente i koji odgovara njihovim potrebama. 

Nadgledanje platnih sistema obuhvata sledeće aktivnosti: praćenje (monitoring) i 
analizu statističkih podataka, informacija, izveštaja i dmgih dokumenata koji se odnose 
na funkcionisanje platnih sistema i korišćenje instrumenata plaćanja kojima raspolaže 
Narodna banka Srbije i procenu usklađenosti platnih sistema s međunarodnim 
standardima i principima za funkcionisanje platnih sistema utvrđenih odlukom kojom se 
propisuje način nadgledanja platnih sistema (u daljem tekstu: procena usklađenosti 
platnih sistema). Monitoring predstavlja kontinuiranu aktivnost čije obavljanje ima za 
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rezultat izradu različitih izveštaja koji doprinose razumevanju funkcionisanja platnih 
sistema, kao i njihove međusobne povezanosti i uticaja na hnansijsku stabilnost zemlje. 
Procena usklađenosti platnih sistema predstavlja periodičnu aktivnost koja se obavlja s 
ciljem sagledavanja usklađenosti tih sistema s međunarodnim standardima i principima 
za funkcionisanje platnih sistema. Navedena aktivnost nije usmerena na individualne 
učesnike u sistemu, već na platni sistem u celini i obavlja se u skladu sa Metodologijom 
za procenu usklađenosti platnih sistema. 

Narodna banka Srbije definiše smemice za primenu principa za funkcionisanje platnih 
sistema kako bi na transparentan način prikazala standarde kojima se rukovodi prilikom 
obavljanja procene platnih sistema, kao jedne od aktivnosti u okvim nadgledanja. Na 
osnovu rezultata monitoringa platnih sistema i procene usklađenosti tih sistema, 
Narodna banka Srbije može predlagati i inicirati izmene u platnim sistemima i to putem: 
davanja preporuka operatom platnog sistema o sprovođenju neophodnih izmena koje su 
od značaja za njegovo sigurno i efikasno funkcionisanje („moralno ubeđivanje”), 
međusobne saradnje organizacionih delova Narodne banke Srbije, izmena i dopuna 
pravne regulative kojom se uređuje platni promet u zemlji, kao i donošenjem različitih 
smemica i prepomka kojima će se obezbediti ispunjavanje osnovnih ciljeva 
nadgledanja. 

Radi transparentnosti, Narodna banka Srbije rezultate nadgledanja prezentuje u okvim 
Godišnjeg izveštaja o stanju u finansijskom sistemu zemlje, kao i kroz različite izveštaje 
koje objavljuje na svojoj Intemet stranici. U obavljanju nadgledanja Narodna banka 
Srbije obezbeđuje poverljivost određenih statističkih podataka, informacija i dmgih 
dokumenata koji se odnose na funkcionisanje platnih sistema i koristi ih samo u svrhu 
obavljanja aktivnosti koje obuhvata nadgledanje tih sistema. Narodna banka Srbije, radi 
uspešnog obavljanja nadgledanja i ispunjavanja postavljenih ciljeva, aktivno sarađuje sa 
drugim relevantnim institucijama na nacionalnom i međunarodnom nivou, kao i sa 
centralnim bankama drugih zemalja. 
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4 Infrastruktura elektronskog poslovanja platnih sistema 

4.1 Internet tehnologije 

Informaciona tehnologija koja je najradikalnije promenila svet i najviše doprinela 
internacionalizaciji i globalizaciji je Internet. Nijedna tehnologija do sada, u tako 
kratkom vremenskom periodu, nije ostvarila brži razvoj i snažniju primenu od Intemeta. 
Za afirmaciju ove informacione tehnologije, između mnogih, zaslužne su sledeće 
činjenice: 

• Intemet se smatra nosiocem novog talasa digitalne revolucije; 

• Ogroman kapital je usmeren na razvoj Interneta, globalnog informatičkog 
projekta, jedinstvenog informatičkog prostora; 

• Internet je infrastmkturna i komunikacijska pretpostavka koncepta svetske 
ekonomske globalizacije, modemog e-poslovanja. 

Intemet funkcioniše kao jedinstvena globalna mreža. Predstavlja decentralizovan sistem 
više autonomnih lokalnih i globalnih mreža međusobno povezanih na osnovu istog 
skupa protokola. Decentralizovana organizacija mreže doprinosi njenoj otpomosti na 
otkaze - otkaz bilo kog dela mreže ne utiče na ostatak mreže. Sam način povezivanja 
autonomnih celina u jedinstvenu mrežu bio je podložan stalnim promenama. Današnja 
arhitektura Intemeta može se opisati kao skup međusobno povezanih logičkih celina, 
koju čine mreže pojedinih provajdera i njihovih korisnika. 

Intemet označava globalni informacioni sistem koji je logički međusobno povezan 
globalnim jedinstvenim adresnim prostorom zasnovanim na Intemet protokolu (IP) ili 
njegovim budućim ekstenzijama; može da omogući komunikacije korišćenjem 
Transmission Control Protocol/Internet Protocol-a (TCP/IP) ili njegovih budućih 
ekstenzija i/ili drugih IP kompatibilnih protokola; i omogućava, koristi ili čini 
dostupnim, bilo javno ili privatno, usluge visokog nivoa koje se oslanjaju na 
komunikacionu ili sličnu infrastmktum [225]. Iako je arhitektum globalne mreže teško 
sagledati u celini, stmktura se danas može podeliti na tri nivoa: korisnički nivo ( user 
levet), pristupni nivo ( access levet), nivo jezgra (core level). Korisnički nivo obuhvata 
mreže krajnjih korisnika koje mogu biti povezane korišćenjem jednog linka (single- 
homed) ka jednom davaocu Intemet usluga - Internet provajdem (ISP) ili više 
nezavisnih fizičkih i logičkih veza (multi-homed) ka više nezavisnih provajdera. 
Infrastmktum intemeta čini nekoliko glavnih komponenata [93]: kičma (backhone), 
mteri (digitalni preklopnici), tačke pristupa (POP i NAP), serveri, korisnički računari. 

4.1.1 Komunikacioni protokoli na internetu 

Da bi računari povezani u mrežu mogli međusobno da komuniciraju, neophodno je da 
se usvoje pravila za komunikaciju, zajednička za sve koji žele da pristupe mreži. Skup 
pravila i normi koji opisuje postupke koji se primenjuju u računarskim 
telekomunikacijama naziva se protokol [74]. Pravila i konvencije koji se koriste u 
komunikaciji između dva sloja n dva računara zovu se protokol sloja n. Protokol 
predstavlja u osnovi dogovor između dve jedinice o načinu komuniciranja. Za elemente 
odgovarajućih slojeva na različitim računarima kaže se da su ravnopravni. Ravnopravni 
elementi mogu da budu procesi, hardverski uređaji, ili čak ljudi. U stvarnosti se nikad 
ne prenose podaci direktno od sloja n jednog sistema ka sloju n dmgog sistema. Svaki 
sloj prosleđuje podatke i upravljačke informacije sloju ispod sebe, sve do najnižeg sloja. 
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Ispod najnižeg sloja je fizički medijum kroz koji se odvija stvama komunikacija. 
Između svaka dva susedna sloja nalazi se interfejs. Interfejs određuje osnovne operacije 
i usluge koje donji sloj nudi gomjem sloju. Osnovni elementi protokola su sintaksa 
(format podataka i nivo signala), semantika (upravljačke informacije, upravljanje 
greškama), timing- signali za sinhronizaciju (podešavanje brzine prenosa, 
sekvenciranje). 

Skup slojeva i protokola naziva se arhitektura mreže. Specifikacija arhitekture mreže 
mora da sadrži dovoljno informacija kako bi realizator mogao da za svaki sloj napiše 
program ili projektuje hardver koji će slediti pravila odgovarajućeg protokola. Lista 
protokola koju koristi određeni sistem (jedan protokol po sloju), naziva se skup 
protokola (protocol stack). 

TCP/IP predstavlja gmpu protokola, od kojih svaki ima specifičnu ulogu, dok je sam 
naziv zapravo akronim dva najvažnija protokola iz grupe - transportnog TCP protokola 
( Transmission Control Protocol) i mrežnog IP protokola ( Internet Protocol). TCP/IP 
slojevi su: 

• Fizički sloj ( Physical layer) - definiše električne i mehaničke osobine koje mora 
da zadovolji prenosni medijum, kao i formate signala koji se koriste na 
medijumu za prenos. 

• Sloj veze ( Data link layer) - definiše fonnate paketa koji se prenose po fizičkom 
medijumu, kao i postupke detekcije i eventualne korekcije grešaka u prenosu. 

• ARP ( Address Resolution Protocol) - definiše postupak konverzije 32-bitne 
Intemet (IP) numeričke adrese u adresu razumljivu sloju veze i vezan je za 
konkretnu mrežnu tehnologiju. 

• IP ( Internet Protocol) - obavlja zadatke vezane za usmeravanje (mtiranje) 
paketa u mreži, u zavisnosti od polazne i odredišne Intemet (IP) adrese. 

• UDP ( User Datagram Protocol) - vrši razvrstavanje datagrama prema 
aplikacijama (npr. datagrame koji pripadaju Telnet servisu, datagrame koji 
pripadaju FTP servisu itd.), odnosno, vrši multipleksiranje prema servisima. 

• TCP ( Transmission Control Protocol) - osim što vrši multipleksiranje paketa 
prema servisima, TCP obavlja niz složenijih zadataka vezanih za uspostavljanje 
i raskidanje veze, kontrolu ispravnosti i redosleda paketa na prijemu, kontrolu 
toka podataka itd; TCP obavlja potpunu kontrolu ispravnosti podataka na 
krajevima veze, zahteva ponovno emitovanje paketa ako primeti da paket nije 
stigao ili je stigao oštećen, vrši kontrolu toka podataka, u smislu dinamičkog 
propuštanja veće ili manje količine podataka u jedinici vremena. 

Aplikativni sloj ( Application laver) - predstavlja skup protokola vezanih za 
funkcionisanje pojedinih aplikacija. Na primer, FTP (File Transfer Protocol) definiše 
protokol vezan za prenos datoteka; SMTP (Simple Mail Transfer Protocol) definiše 
procedum razmene elektronske pošte između dva sistema priključena na Intemet; HTTP 
(Hyper-Text Transport Protocol) jc protokol kojim se prenose elementi (tekstovi, slike, 
zvučni zapisi) koji čine veb-prezentaciju itd. 

U nastavku su primeri protokola mreža [161]: 
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WAN 

HDLC ( High-level Data Link Control) koji predstavlja grupu protokola namenjenu za 
prenos podataka između čvorova u mreži. Podaci su organizovani u frame-ovc. HDLC 
je protokol drugog sloja OSI modela (Sloj voda podataka). Prenos HDLC paketa je 
sinhron i fizički sloj treba da obezbedi odgovarajuće metode za sinhronu predaju i 
prijem ovih paketa 

LAPB (Link Access Procedure, Balanced) jc protokol sloja voda podataka namenjen za 
komunikaciju između DTE i DCE u Х.25 protokol stack- u koji je izveden iz HDLC 
protokola, to je Point to Point protokol i koristi Asvnchronous Balanced Mode (ABM) 
transfer mod. Veoma je robustan i koristi se u serijskoj komunikaciji, kao i u satelitskim 
vezama. 

Frame Relay protocol je protokol drugog sloja OSI arhitekture. Koristi se za 
povezivanje LAN mreža i krajnjih tačaka WAN mreža. Ram Frame Relay protokola 
prenosi se preko virtuelnih kola (logički definisani putevi od izvora do odredišta). Može 
prihvatiti različite tipove podataka. 

Х.25 mreža se može podeliti po vrsti uređaja koje povezuje u tri grupe: Data Terminal 
Equipment (DTE) grupu sa krajnjim uređajima u mreži (tenninali, personalni računari), 
Datci Circuit-terminating Equipment (DCE) sa komunikacionim uređajima (modemi, 
switch-Q\ i) i Packet Switching Exchange (PSE) switch-evi koji čine osnovu prenosne 
mreže i oni prenose podatke između DTE kroz Х.25 PSN ( Public Switching Network ). 
Х.25 protokol je definisan od strane ITU kao implementacija prva tri sloja OSI modela. 

LAN 

Ethernet protokol se može uzeti kao primer protokola LAN mreža koji obuhvata 
funkcije fizičkog sloja i sloja voda podataka. Originalna verzija Ethernet protokola 
(Ethernet Version ) kreirana je od strane kompanija Digital, Intel i Хегох i poznata je 
pod nazivom DIX, dok je IEEE 802.3 definisan kasnije. Oba ova standarda, odnosno 
tipa frame-ov a mogu koegzistirati u istoj mreži, koristeći istu tehniku pristupa 
medijumima prenosa - tehniku višestrukog pristupa sa nadgledanjem nosioca i 
detekcijom kolizije. 

Primeri LAN protokola su i Internet protokol verzija 4 (IPv4), Internet protokol verzija 
6 (ПЧ6), UDP protokol, UDP protokola za komunikaciju u realnom vremenu, odnosno 
RTP protokol, ICMP protokol ( Internet Control Message Protocol, koji pomoću 
odgovarajućih kontrolnih poruka dobija povratnu infonnaciju o stanju i eventualnim 
problemima koji postoje u mreži). 

Primeri alata baziranih na ICMP protokolu: 

• Ping koji koristi Echo Request i Echo Replv poruke, svaka Echo poruka sadrži 
broj sekvence (inicijalno 0) koja se inkrementuje za 1 nakon svake transmisije i 
vremensku markicu ( Timestamp ) koja govori o vremenu transmisije, a koristi se 
za testiranje dostupnosti odredišta, vremena potrebnog za prenos paketa, 
brojanje hopova do odredišta (ukoliko ne dobijemo odgovor, ne znači da je 
odredište nedostupno). 

• Traceroute se kao i ping koristi za proveru dostupnosti odredišta, ali daje i 
infonnaciju o prenosnom sistemu (npr. IP ruterima) između izvora i odredišta, 
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koristi ICMP echo poruke adresirane na odredišnu IP adresu i koristi se TTL 
brojač hopova, pri čemu se „primorava” svaka deonica da vrati poruku ,,greška“. 

4.1.2 XML tehnologije 

XML ( eXtensible Markup Language) [229] je zasnovan na istim principima kao i 
SGML, ali je znatno jednostavniji i prilagođen je veb-u. Kao i SGML, i XML se koristi 
za definisanje drugih jezika, pa se naziva i metajezik. Međutim, XML je mnogo 
jednostavniji od SGML-a. XML je jezik oznaka koji ne ograničava skup oznaka koje se 
mogu koristiti, niti gramatiku tog jezika. 

Postoje dva osnovna koncepta kod XML dokumenta. Prvi koncept uslovljava da svaki 
XML dokument mora biti dobro strukturiran. Dobro strukturiran dokument je onaj čiji 
su svi otvoreni tagovi i zatvoreni, i to po istom redosledu, te korišćena sintaksa sledi 
specifikaciju. Drugi koncept XML dokumenta je validnost dokumenta. Validan 
dokument je onaj koji odgovara definiciji tipa dokumenta (DTD - Document Туре 
Defmition). DTD tačno navodi oznake i raspored elemenata koji se mogu koristiti u 
XML dokumentu. On predstavlja proširenje XML dokumenta, opisujući njegove 
gradivne elemente. Pomoću DTD-a može se definisati struktura dokumenta kreiranjem 
liste dopuštenih elemenata [39]. 

XML je metajezik, koji služi za opis drugih jezika. Omogućava razvoj tipova podataka, 
u cilju identifikacije i korišćenja informacija u dokumentima. Podaci u XML-u se 
predstavljaju u strukturi stabla, pri čemu svaki čvor stabla može da se tretira kao 
poseban objekat. U XML-u akcenat je na opisu podataka. Preko preciznog opisa i 
validacije podataka smanjuje se mogućnost primene proceduralnih alata, čime se 
olakšava proces obrade podataka i smanjuje broj grešaka. Podaci opisani u XML-u 
nezavisni su od platforme na kojoj se koriste. XML je koncipiran sa idejom da omogući 
punu iskorišćenost i međuoperativnost World Wide Web-a. 

XML je kreiran sa namerom da bude jednostavan za učenje, jeftin, brz i optimizovan za 
Intemet. XML se naziva i eXcellent Marketing Language jer predstavlja: 

• univerzalni format podataka, XML omogućuje kreiranje sopstvenih formata 
podataka i njihovu razmenu preko postojećih mreža i aplikacija; 

• integraciju podataka, XML vrši jednostavnu integraciju podataka kod već 
postojećih aplikacija i platformi; 

• prilagodljiv, razumljiv jezik i za čoveka i za mašinu, primaoca i pošiljaoca, te 
predstavlja najupotrebljiviji standard za manipulaciju podataka i njihovu 
razmenu. 

Svrha XML je da generiše sopstvene tagove, njihovo značenje i njihov prikaz. XML 
opisuje stmkturu podataka, integriše protokole i obezbeđuje razmenu podataka. 
Odnosno, predstavlja skup pravila koja omogućavaju opis podataka u tekstualnom 
formatu. Primeri primene XML su: 

• XML for Content Providers. Istoj informaciji može se pristupati i ona se može 
čitati na različitim jezicima. Svaki XML dokument može da sadrži opis 
gramatike ili sintakse kako bi se mogao proveriti i ispraviti sadržaj. 

• XML for Content and Knowledge Management. XML nosi informaciju o 
sadržaju pa su pretraživanje, indeksiranje i pronalaženje podataka jednostavniji. 
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Transformacija podataka iz XML omogućava prikaz na različite medije (veb, 
CD ROM, papir), bez nepotrebnih modifikacija i dupliranja sadržaja. 

• XML for Content Aggregation. XML obezbeđuje da se informacije sa različitih 
mesta integrišu na jednom mestu. 

• XML for Electronic Document Interchange. XML omogućava kreiranje 
strukture za razmenu infonnacija i objedinjuje postojeće protokole i standarde. 

• XML and E-Commerce. XML obezbeđuje sintaksu za identifikaciju infonnacija 
potrebnih za obavljanje poslovnih transakcija. 

• XML for Design. Scalable Vector Graphic (SVG) predstavlja jezik za opis 
dvodimenzionalnih vektora kojima se predstavljaju grafički elementi 
korišćenjem XML-a. 

XML-ov model podataka je predstavljen na slici 12. 



C^) Dokument 



Specifikacija 

(vred.čvorova) 


čvorovi stabla sadrže podatake 



Atributi 


Slika 12. XML model podataka 

Svi čvorovi u XML dokumentu formiraju stablo dokumenta (ili stablo čvorova). Svaki 
element, atribut, tekst itd. u XML dokumentu predstavlja čvor u stablu. Stablo počinje 
čvorom dokumenta i nastavlja da se grana sve dok ne obuhvati sve tekstualne čvorove 
na najnižem nivou stabla. 

Termini ,,roditelj“ ( parent ) i ,,dete“ (child) koriste se da bi opisali odnos između 
čvorova. Neki čvorovi mogu da imaju čvorove decu, dok drugi čvorovi nemaju decu 
(čvorovi listovi). Zato što je XML dokument strukturiran u fonni stabla, može biti 
prenesen bez poznavanja tačne strukture stabla i bez poznavanja tipova koji su sadržani 
u njemu. 

4.1.2.1 Sintaksna interoperabilnost i XML 

Sintaksna interoperabilnost služi prevazilaženju jaza između formata podataka, 
standarda jezika, operativnih sistema i hardverskih platformi [227]. Od posebnog 
interesa je interoperabilnost, koja se tiče mogućnosti da dva sistema prepoznaju 
zajednički standard obrade i prezentacije podataka. Danas najrašireniji sintaksni 
standard jeste XML (Extensible Markup Language). XML je jezik koji se koristi za 
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opisivanje strukture podataka. Njegove mogućnosti mogu da dođu do izražaja svuda gde 
se obavljaju operacije ulaza i izlaza, memorisanja ili prenosa podataka sa jednog mesta 
na drugo. Verovatno najpoznatija oblast njegove primene je rad na mreži, posebno u 
slučaju mobilnih uređaja čija se tehnologija komunikacije sa mrežom bazira na XML-u. 
XML je preteča WAP-a i WML-a. 

XML je standard razvijen u WWW Konzorcijumu {World Wide Web Consortium - 
W3C), organizaciji koja određuje opšti smer kojim se veb razvija. W3C grupa zadužena 
za XML opisala je XML na sledeći način: „Proširivi markerski jezik (XML) je 
potkategorija standardnog opšteg markerskog jezika ( Standard Generalized Markup 
Language, SGML). Njegov cilj je da izvomom SGML-u omogući postavljanje, 
preuzimanje i obradu na vebu na način kako je danas to moguće sa HTML-om. XML je 
napravljen sa ciljem da bude jednostavan za primenu i da omogući kombinovanu 
upotrebu sa SGML-om i HTML-om.“ 

XML je fleksibilan način kreiranja podataka zajedničke strukture. Takav zapis podataka 
omogućava da se preko mreže prenose istovremeno dve stvari: podaci i njihova 
struktura. Oznake (tag) ga čine samoopisnim i lako razumljivim među ljudima, ali i 
programima. XML mogu koristiti pojedinci, gmpa pojedinaca ili kompanije koje žele 
razmenjivati informacije na konzistentan način. 

XML definiše otvoreni, fleksibilni standard za opisivanje, smeštanje, objavljivanje i 
razmenu bilo koje vrste informacija. Poslovni podaci izraženi XML-om oslobođeni su 
ograničenja privatnih formata i trebalo bi da budu razumljivi i nakon što zastare 
računarski sistemi na kojima su nastali i sistemi za rad s bazama podataka gde su bili 
smešteni. XML-om se mogu opisati i izraziti različite vrste podataka; tako, na primer, 
postoje XML standardi dokumenata (DTD - Document Туре Definition) za finansijske 
podatke, bibliografiju, genetski kod, elektronsko poslovanje - ebXML itd. 

Prvi standard za prezentaciju stmkturiranih dokumenata bio je SGML ( Standard 
Generalized Markup Language), usvojen od strane ISO-a ( International Standards 
Organisation) 1986. godine. Ovaj standard se oslanjao na viziju tzv. stmkturiranih 
dokumenata. Taj pojam je obuhvatao težnju da se pre kreiranja dokumenata njihova 
logička stmktura odredi unutar zacrtanog okvira. Taj okvir se zove DTD ( Document 
Туре Definition). Unutar DTD-a hijerarhijska stmktura delova dokumenata je 
definisana, gde je moguće te delove dokumenata povezati s atributima koji celini dodaju 
semantičke informacije, tj. informacije o značenju. Krajem osamdesetih, uz razvoj veb 
platforme, na osnovu SGML-a razvijen je i HTML ( Hypertext Markup Language), još 
uvek prisutni standard za prezentaciju onlajn dokumenata. Godine 1998, od strane 
W3C-a, razvija se XML. HTML opisuje kako sadržaj (veb stranice) treba da izgleda, ali 
on ne daje informaciju o stmkturi i značenju podataka. XML, s dmge strane, izdvaja 
sadržaj od njegove prezentacije i definiše način označavanja za različite scenarije, tj. 
upotrebe. To znači da je DTD unutar HTML-a fiksiran, dok je kod XML-a prilagodljiv. 
Dmgim rečima, kod XML-a nazive elemenata (tagova) može definisati onaj ko pravi 
XML dokument. 

U velikim organizacionim stmkturama u elektronskom poslovanju platnih sistema 
postoji veliki broj različitih organizacionih jedinica, koje bi mogle biti sklone korišćenju 
različitih XML rečnika. U slučaju da dva ili više različitih autora koriste dva ili više 
elemenata sa istim imenom, a ti elementi pripadaju različitim rečnicima, onda se ti 
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spomi elementi povezuju s XML prostorima imena ( name-spaces ), pomoću kojih se 
clcfi niše način razlikovanja tih elemenata. 

4.1.2.2 XML dokument 

XML dokument čini skup strukturiranih podataka smeštenih u neku vrstu pomke koja 
opisuje podatke. XML dokumenti mogu biti datoteke, kao i pomke koje se mogu 
prenositi Intemetom, ali i između komponenata jednog računala. Sintaksa tih 
dokumenata može, ali ne mora, biti čitljiva čoveku, a sam dokument može sam sebe 
opisivati. Međutim, XML dokumenti ne moraju biti dokumenti u tradicionalnom smislu, 
mogu biti i podaci izvučeni npr. iz relacionih baza podataka. Takođe, XML dokumenti 
mogu se obrađivati i na servem (kada dva servera razmenjuju podatke bez intervencije 
čoveka) i kod klijenta. Posebno bitan tip XML dokumenata su XML šeme koje tumače 
deljene rečnike (između više korisnika) i daju mogućnost uređajima da se ponašaju u 
skladu sa ljudskim pravilima, na način da pmžaju osnovu za definisanje stmkture, 
sadržaja i semantike XML dokumenata. 

4.1.2.3 XML šema kao standard za podatke 

U smislu tehnologije, evropska bankarska industrija je odredila da standardni SEPA 
format podataka bude baziran na XML-u (ISO 20022 [112]) za transport platnih pomka. 
U budućnosti ovaj unifonnni tehnički standard će biti polazište za transparentnu platnu 
infrastmktum u jedinstvenoj evropskoj platnoj zoni što će omogućiti potpunu 
automatizaciju izvršenja plaćanja. 

ISO 20022 - UNIversal Financial Industry Message scheme (UNIFI) je intemacionalni 
standard koji definiše ISO platfonnu za razvoj finansijskih standarda. Pristup prisutan u 
šemama poslovnog modeliranja omogućava korisnicima i informatičarima da prezentuju 
finansijske poslovne modele i pripadajuće transakcije sa formalnom sintaksno 
nezavisnom notacijom. Ovi poslovno-transakcioni modeli su stvarni poslovni standardi. 
Oni mogu biti prevedeni u fizičke pomke željene sintakse. U vreme kada je UNIFI 
počeo sa razvojem, XML (eXtensible Mark-up Language) je već bio vodeća sintaksa za 
e-komunikaciju. 

Ako ne postoje UNIFI poruke koje pokrivaju specifične transakcije, može se 
inicijativom definisati novi model i pomke koje će odobriti UNIFI registraciono telo. 
Ako pomka postoji u repozitorijumu, ali ne zadovoljava sve potrebe, može se 
inicijativom kreirati nova verzija pomka koja će ih prilagoditi potrebama. Ekvivalentan 
način zadavanja standarda koriste i ostale organizacije koje svoje elektronsko 
poslovanje baziraju na XML baziranim standardima, te na taj način XML šema postaje 
standard za podatke. 

XSD šeme, kao standard za podatke, mogu se iskoristiti kao osnova objektno - 
relacionog mapiranja [77]. Kao dokaz, može se izvesti generisanje šeme baze podataka 
iz XSD šeme. Postoje i alati koji taj zadatak mogu obaviti. Objektno - relaciono 
mapiranje je skup obrazaca za kreiranje i metode koja omogućava da objektno 
orijentisana stmktura podataka može perzistirati u relacionoj bazi podataka. Objektno - 
relaciono mapiranje je važan deo skoro svakog sistema koji koristi relacioni sistem 
upravljanja bazama podataka. Veoma je važno objektno - relaciono mapiranje primeniti 
na pravi način pošto i izrada stmkture baze podataka i stmkture objekata zavise od tog 
mapiranja. Transformacija podataka iz objekata u memoriji i obratno može umanjiti 
performanse, mogućnost skaliranja sistema i robusnosti sistema. Kompleksne 
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nekonzistentne tehnike mapiranja mogu biti teške za realizaciju i baze podataka i 
aplikativnih elemenata sistema. Baza podataka je, uobičajeno, zajednička za više 
aplikativne elemente sistema, od kojih mnogi mogu biti razvijeni mnogo nakon što je 
realizovana baza podataka. Postoji mnogo alata, veći broj metodologija i obrazaca za 
realizaciju mapiranja. Osnovni zahtev je centralizacija definicija šema u obliku koji 
može biti konvertovan u objektno orijentisanu i relacionu strukturu. XSD je jedna od 
takvih reprezentacija. XSD šema dozvoljava da se defi nišc bogata struktura podataka 
koja može biti konvertovana i u objektno orijentisanu strukturu i relacionu strukturu. 
Bez obzira na kompleksnost, XSD je praktično najbolji izbor u odnosu na alternative i 
otvara mnoge mogućnosti za inovacije u integraciji. Na primer, u potrazi za osobinom 
sistema, dodajući osobinu XSD šemi, tu osobinu možemo automatski direktno objektu i 
tabeli u isto vreme. Ukoliko se ontologija izmeni, može se proizvesti XSD baziran na 
izmenjenoj ontologiji, što će se odraziti i na objektnu i relacionu strukturu sistema. 
Osnovna korist od korišćenja XSD šeme je činjenica da je dovoljno definisati šemu 
samo jednom, dok u suprotnom postoji potreba da se definisanje vrši dva puta za 
objektno orijentisane elemente i ponovo za relacione strukture. Objektno - relaciono 
mapiranje je jedan od osnovnih elemenata arhitekture aplikativnih sistema u poslovanju. 

Proširivi jezik za označavanje, u oznaci XML je format podataka koji omogućava 
razmenu podataka između istih ili različitih računarskih sistema bez potrebe pisanja 
programa ili ,,interfejsa“. Značenje skraćenice XML je sledeće: „Extensible” (proširiv) 
jer nije ograničen na jednu upotrebu ili jednu aplikaciju. „Markup'" (označiti) jer 
identifikuje infonnacije - posebno polje po polje ili elemente od kojih se sastoji poruka. 
„Language” (jezik) jer je skup pravila ili ,,protokol“. Proširivi jezik za označavanje - 
XML je fleksibilan, javni skup standarda za označavanje i organizaciju informacija 
koje, na taj način priređene, mogu biti transportovane putem mreže kao što je internet i 
spremne za interpretaciju od strane različitih računarskih sistema. Tehnički, XML može 
biti opisan kao od platfonne nezavisan, samoopisujući, proširiv standard za razmenu 
informacija. Proširivi jezik za označavanje - XML je samo metajezik - dijalekti mogu 
biti razvijeni kao standard, da podrži različite tipove poruka predviđenih za jednu vrstu 
posla. 

Kada se zapišu kao XML, podaci mogu biti deljeni ili transportovani preko različitih 
sistema, bez obzira da li su ti sistemi interni ili eksterni - između različitih organizacija. 
U odnosu na flat fajl (txt fajl sa infonnacijama odvojenih zarezom ili slično), XML 
poseduje dodatnu dimenziju u povećavanju stepena integracije podataka. 

Pretpostavimo da Preduzeće A snabdeva Preduzeće B sa podacima u CSV ( Comma 
Separated Values ) formatu. Ukoliko Preduzeće A omaškom upiše neki podatak loše u 
CSV fajl, šanse da će CSV fajl biti dobro importovan u sistem Preduzeća B sa 
saznanjem koji podaci su loše upisani, jesu male, a postoji i verovatnoća da će loše 
formatirani podaci izazvati neregularan rad sistema Preduzeća B. U XML fajlu se zna 
na koji način će podaci biti prezentovani i biće uočeni loši podaci. Isto tako, može biti 
izvršena i provera podataka na osnovu odgovarajuće XSD šeme (XML Schema 
Document) koja može biti poslata sa odgovarajućim XML fajlom. 

Kada Preduzeće A želi da pošalje CSV fajl sa podacima hijerarhijske strukture (kao 
primer možemo uzeti listu faktura sa pripadajućim detaljnim opisima stavki po 
fakturama), tada se stvari obično iskomplikuju bilo sa složenošću strukture fajla ili sa 
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višestrukim fajlovima u kojima su predstavljeni podaci, a delom i isti podaci u različitim 
fajlovima, na primer, podaci koji su potrebni da se predstavi deo ili čitav ključ sloga. 

Za XML takva struktura nije potrebna jer je u njemu uključen mehanizam koji 
obezbeđuje hijerarhijsku strukturu podataka odgovarajućom strukturom XML atributa. 

XML je objektno orijentisan, u smislu pogodnosti opisivanja objekata realnog ili 
apstraknog sveta iz bilo kog problemskog domena uzimajući u obzir osobine objekata, 
umesto nasilnog uvođenja normalizovanih dekompozicija u različitim tabelama 
povezanim relacijama. Ovo čini XML dokumente i intuitivno razumljivijim i zbog toga 
čini lakšim potreban dizajn aplikativnih struktura, kao i implementaciju sistema 
baziranih na XML strukturama. 

Iako se ne ističe kao glavna osobina, jedna od glavnih prednosti XML fajla jeste 
čitljivost podataka od strane čoveka i na taj način se uvećavaju mogućnosti generalne 
podrške i mogućnosti u razvoju elemenata odgovarajućeg sistema. Kao ilustracija 
navedenog može da posluži sledeći primer: 

reprezentacija podataka uz pomoć flat fajla je 

GBPNABB20031204335423 

a reprezentacija istih podataka u obliku XML dokumenta je 

<Currency> GBP </Currency> 

<Bank> NABB </Bank> 

<Year> 2003 </Year> 

<Month> 12 </Month> 

<Day> 04 </Day> 

<Hour> 33 </Hour> 

<Minute> 54 </Minute> 

<Second> 23 </Second> 

gde je vidljiva razlika u prezentaciji podataka, kao i znatno bolja čitljivost i razumljivost 
XML prezentacije podataka. 

Proširivi jezik za označavanje - XML je globalan. Za bolje razumevanje pažnje koju je 
XML privukao, korisno je podsetiti se drugog široko zastupljenog standarda koji danas 
svi koriste: ASCII ( American Standard Code for Information Interchange ). 

ASCII usredsređen na konkretan alfabet i sistem za pisanje ima za osnovnu 
pretpostavku da dozvoljava različitim računarskim sistemima i operativnim sistemima 
da razumeju razmenjene podatke. U okviru adaptacije u Unicode 1.0 i nastavak 
evolucije, ASCII ideja je proširana da obuhvati sve jezike i sisteme za pisanje u svetu. 

Savremeni računarski sistemi danas imaju sposobnost da generišu, čitaju i procesiraju 
tekst dokumente bazirane na ASCII ili Unicode standardu. Proširivi jezik za 
označavanje - XML prihvatio je takav pristup i otišao korak dalje, gradeći na Unicode 
standardu univerzalan način da opiše strukturu podataka za razne namene. 
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Dijagram je uprošćena i strukturirana vizuelna reprezentacija koncepta, ideje, 
konstrukcije, relacije, statistike, anatomije i slično, korišćena u svim ljudskim 
aktivnostima u smislu vizualizacije i uprošćavanja sadržaja. Dijagrami su, dakle, 
ilustracije sa skupom simbola koji su speciiični za posebnu namenu. Simboli koji se 
pojavljuju na XML dijagramima su: 

Element: Osnovni deo dijagrama je imenovani pravougaonik. Svaki od njih predstavlja 
simbol zvani element. Svaki element može biti snabdeven dodatnim informacijama, kao 
što je prikazano na Slici 13. 


partyld 

type 

xs:string 

enum 



Slika 13. Gralički simbol za predstavljanje elementa 

Ovo je mandatory i prost element tipa string. Gomji levi ugao ima osenčenje koje 
ukazuje na podatke sadržane u ovom elementu, a type specificira da su podaci tipa 
string. Ukoliko postoji enumeracija (tj. lista određenih vrednosti), tada će ,,enum“ ćelija 
da sadrži listu. 

Opcioni element: Na slici 14. prikazan je grafički simbol opcionog elementa. Opcioni 
element se predstavlja isprekidanom linijom. Komentari u okviru elementa daju dodatne 
detalje koji opisuju taj element. 


;^partyMame 

-|type 

xs:string; 

lenum 



Slika 14. Grafički simbol za predstavljanje opcionog elementa 

Ponavljajući element: Element prikazan na slici 15. je element koji sadrži dmge 
elemente koji se ,,otkrivaju“ ukoliko se element ,,razvije“ uz pomoć znaka „+“, koji se 
nalazi na desnoj stranici. Može da se pojavljuje najmanje jedanput, dok gomja granica 
nije definisana, što se prikazuje simbolom sa desne strane - ,,beskonačno“. 



^partvTradeldentifier Д 


type| Д 


1 ,.co 


Slika 15. Grafički simbol za predstavljanje elementa koji se ponavlja 


Konektor sekvence: Konektor sekvence na slici 16. označava da je dateRange 
sastavljen od maksimalno tri elementa. U slučaju prikazanom na slici svaki od ovih 
elemenata je opcioni, ali u nekim drugim slučajevima jedan, više ili svi elementi mogu 
biti obavezni. 


Slobodan Babić \ Fakidtet organizacionih папка 


90 





















Doktorska disertacija: Model interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama 


l^beginDate ; 

-;lype 

xs:date; 

lenum 

J 



dateRange Ј 

( v-L_i 


l Ј-г г 


lendDate 


~;type 


xs:date 


ienum 


^dateType 

type 

xs:string ; 

enum 

VALUEDATE TRADEDATE I 


Slika 16. Grailčki simbol za predstavljanje konektora sekvence 

Konektor izbora: Konektor na slici 17. je indikator izbora. To znači da će kod 
jinancialTerms biti uvek izabran tačno jedan od elemenata koji se nalaze sa desne 
strane. 



Slika 17. Grafički simbol za predstavljanje konektora izbora 

Definicija korišćenja kompleksnog tipa: Dijagram na slici 18. ilustruje korišćenje 
kompleksnog tipa za definisanje elementa. Prvo se definiše tip Quote. Kada se kreira 
forwardPointsQuote, kao kompleksan, njegov tip se definiše kao Quote. Kao posledica 
toga, element foi^wardPointsQuote automatski preuzima definiciju specificiranu za 
Quote. Ovakve konstrukcije elemenata su česte kada se koriste isti elementi u mnogo 
različitih uloga, da se isti tip ne bi na svim mestima više puta definisao . 



Slika 18. Primer grafičkog predstavljanja kompleksnog tipa 

Kompleksan tip: Na prvi pogled, slika 19. kompleksan tip je veoma sličan normalnom 
elementu. Ono što taj elemenat čini moćnim jeste da on može da bude ponovno korišćen 
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za specifikaciju različitih elemenata koji imaju identične zahteve po pitanju atributa. 
Ovo je učinjeno tako da se kompleksan tip ne vidi eksplicitno u rezultujućem XML-u. 
Kada se izvrše promene kompleksnog tipa, svaki element koji je sa njim definisan biće 
promenjen u skladu sa izvršenom izmenom. 


| Ouote 


bidRate 


type 

Rate 

enum 




^offerRate 

type 

Rate 

enum 



^midRate 

lype 

Rate 

enum 



Slika 19. Grafička predstava kompleksnog tipa koji se koristi u definicijama 

TWIST poruka : Poruke neprofitne organizacije TWIST ( Transaction Workflow 
Innovation Standards Team) [213] jesu primer poruka koje su nastale na osnovu 
IS020022 poruka. Poruke se koriste u Retail domenu (poslovi pravnih i fizičkih lica u 
procesima plaćanja) finansijskog tržišta. Ovim porukama TWIST organizacija daje 
punu podršku procesima razvoja jedinstvene evropske platne zone, prihvatajući 
standarde i metodologiju koju je propisao EPC i to sa proširenim skupom procesa 
finansijske industrije koje ove poruke pokrivaju. Organizacija TWIST se među prvima 
uključila u procese izgradnje jedinstvene evropske platne zone i na taj način sebi 
obezbedila jednu od najznačajnijih uloga u tom domenu. 



Slika 20. Struktura TWIST XML poruke 

Koreni element TWIST poruke je element TwistMessage, slika 20. TwistMessage je 
sačinjen od četiri elementa: messageHeader, conversationldentification, conversation 
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element, i element party. Zaglavlje poruke ( message header ) uvek je prisutno i koristi 
se za beleženje informacija o tome ko šalje poruku i kome. Sve relevantne informacije o 
fizičkoj pojavi poruke sadržane su u zaglavlju. Element conversationldentification može 
da sadrži i neophodne informacije koje se odnose na ranije poruke. Treći element je 
conversation. Sadrži elemente: tradeConversation, tradeStatementConversation, 
settlementConversation, accountConversations i setupConversations. Na kraju 
TwistMessage je skup elemenata o stranama konverzacije {partv ). Strane koje učestvuju 
u razmeni podataka definišu se na kraju kroz potpunu potrebnu specifikaciju i u poruci 
se na odgovarajućim mestima prosto referencira na taj njihov detaljan opis, umesto da 
se ponavljaju na različitim mestima u dokumentu. 



Slika 21. Struktura zaglavlja TWIST XML poruke 
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Conuersationldentification 


€& 


^conuersationld 

type 

enum 

xs: normalizedString 



. conversationliser 


type 


User 




f messageDateTime 

lype 

xs:dateTime 

enum 



'comment 


: 


;enum 


Text 


Slika 22. Struktura elementa Conversationldentification 

Zaglavlje identifikuje poruku, verziju TWIST poruke koja je korišćena i ko je šalje, 
prikazano na slici 21. Zaglavlje poruke nije formatizovano u smislu protokola za prenos 
poruke mrežnom infrastrukturom. Element messageHeader je deo poruke bez obzira da 
li se poruka prenosi na flopi disku, kao fajl na disku, prebačena ftp-om na neku lokaciju, 
kopirana na CD ili isporučena na bilo koji način na drugu lokaciju. Drugi mehanizmi, 
od kojih neki koriste i informacije iz zaglavlja poruke, služe za prenos poruke. 

Element prikazan na slici 22. koristi se da bi se identifikovao predmet dopisa kome ova 
poruka pripada. Inicijalna poruka dopisa sadrži novu identifikaciju dopisa, t.j. novi 
conversationld. 


Dakle, predmet dopisa je identifikovan sa conversationld. Svaka poruka u razmeni mora 
da ima referencu koja pokazuje kom predmetu konverzacije poruka pripada, i to se čini 
referenciranjem na conversationld. 

Predmet dopisa je podeljen u grupe koje su prikazane na slici 23. Svaka poruka mora 
biti formirana od tačno jednog elementa prikazanog na slici. 



Slika 23. Struktura grupa poslova na koje poruka može da se odnosi 
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Svaki element iz conversation grupe sadrži informacije koje su potrebne za opisivanje 
jedne vrste dopisa. 

Poslednji element u poruci je definicija strana komunikacije. Definicija je neophodna za 
svaku stranu koja je referencirana u telu poruke. Tipični primeri strana su Primalac i 
Pošiljalac. 

fntemacionalne organizacije za standardizaciju poruka svoje specifikacije daju u obliku 
XSD šema sa pratećom nestruktuiranom dokumentacijom koja daje više informacija za 
razumevanje kompleksnosti. XSD šeme predstavljaju osnovu za kreiranje instanci 
poruka. Branislav Lazarević i grupa autora u knjizi ,,Baze podataka‘ L [108] tvrde da je 
takva specifikacija pogodna za izgradnju konceptualnog rnodela odgovarajućih baza 
podataka. U svom magistarskom radu Nenad Aničić uvodi pojam „normalizovanog 
XML dokumenta“. Preko normalizovanog XML dokumenta dolazi se do relacione baze 
podataka, za koju pokazuje da ima zadovoljavajuće karakteristike. 

Aleksis Smirnov u svom radu [194] pokazuje da XSD šema može biti osnova za 
objektno-relaciono mapiranje i dokazuje da se može napraviti alat koji bi prevodio XSD 
šemu u odgovarajući model baze podataka. Pošto u radu Smirnova polazišna XML 
struktura nije normalizovana, ne dobija se baza podataka sa zadovoljavajućim 
karakteristikama, ali primenom standardnih pravila rnože se doći do zadovoljavajuće 
baze podataka. 

4.1.2.4 Resource Description Framework šeme standard za metapodatke 

Rad na Opšem okviru za opisivanje resursa ( Resource Description Framework, RDF) 
započeo je R. V. Guha dok je radio za Apple Computer i njegova prva verzija stekla je 
status W3C Preporuke 1999. Nova verzija objavljena je 2004. [34]. kao skup srodnih 
specifikacija. Strogo govoreći, RDF nije jezik, nego model podataka za opisivanje 
mašinski čitljive semantike za „mrežne resurse”. Matematički govoreći, ovaj model 
sastoji se od usmerenih grafikona sa čvorovima koji su povezani označenim lukovima. 
Kao ključni napredak u odnosu na XML, RDF uvodi strukturu izjavne rečenice u svoje 
podatke. Svaka RDF rečenica ima tri dela. Oni se označavaju ili kao „subjekt”, 
„predikat” i „objekt”, ili kao „objekt”, „atribut” i „vrednost”. Subjekt/objekt, odnosno 
objekt/vrednost, treba da budu shvaćeni kao da leže na čvorovima RDF-ovih usmerenih 
grafikona, a predikati/atributi na lukovima. Semantički govoreći, u svakoj rečenici 
subjekt/objekt treba da budu shvaćeni kao „stvar” o kojoj se u rečenici nešto kazuje, 
predikat/atribut kao svojstvo koje je pripisano subjektu/objektu, a objekt/vrednost kao 
vrednost (ili neki drugi kvalifikator) doznačena tom subjektu/objektu kao da mu 
specifično pripada. 

Budući da je RDF model podataka, a ne jezik, potrebno ga je iskazati u jeziku. Često se 
prikazuje u XML-u, kakav je u službenoj specifrkaciji W3C-a. Međutim, ta verzija je 
nezgrapna u pogledu sintakse. Nešto jednostavnija verzija uključuje N3 i njegov još 
jednostavniji podskup N-Triples. Drugi jezik, razvijen na Univerzitetu u Bristolu, jeste 
TURTLE ( Terse RDF Triple Language ) koji neznatno proširuje N-Triples\ predložene 
su i rnnoge druge verzije. Za uspešnu semantičku interoperabilnost, koja je cilj 
semantičkog veba, aplikacije koje koriste RDF treba da izvedu primenu RDF-a na 
nezavisan način. RDF trodelna struktura iskaza čini ovaj okvir vrlo prilagodljivim jer 
proizvoljan broj tripleta tnože biti „naslagan” po bilo kojem redu. Nasuprot tome, u 
XML-u, raspored u kojem se elementi pojavljuju u dokumentu značajanje : to podosta 
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otežava razmenu podataka. Strukture podataka koje se dellnišu u XML-u takođe su 
dosta složene i sintaksno nezgrapne jer se mogu sastojati od proizvoljnih mešavina 
stabala, gralikona i nizova znakova. RDF-ov triplet usmeren stil modeliranja podataka 
nudi sredstva koja omogućuju graličko strukturiranje podataka raznovrsnih 
dokumenata; s druge strane, XML može iskazati gralikonc samo unutar datog 
dokumenta. Standardni RDF upitni jezik već postoji; svaki je jezik na tipičan način 
povezan s određenom verzijom. 

RDF treba da omogući da se preko Interneta programski obrađuju podaci na isti način 
na koji se u konvencijalnom vebu obrađuje hipertekst. Time se omogućuje distribuirana 
obrada podataka preko veba. Konvencionalni veb podržava korisnički pristup 
dokumentima, ,,stranicama“ tekstova i slika, dok Semantic Web [224], zasnovan na 
RDF-u, treba da podrži pristup bazama strukturiranih podataka. RDF omogućuje 
softversko procesiranje veb-informacija. 

4.2 Metod i paradigme za razvoj informacionih sistema 

Globalizacija je unela mnoge izazove za kompanije. Male kompanije imaju veliku 
prilagodljivost, ali skromna sredstva u domenu odgovora na date izazove. Velike 
kompanije imaju drugačiji problem, širenje poslovanja često za posledicu ima problem 
praćenje informacionih tokova. Čak i manje promene u toku infonuacije mogu dovesti 
do gubitka nekih bitnih elemenata. Dugi niz godina kompanije su nalazile načina da se 
nose sa ovim izazovima i mnoga rešenja su išla i smem stvaranja virtualnih timova ljudi 
koju nisu na istoj geografskoj lokaciji ali rade na istom zadatku. Ovakva rešenja su u 
velikoj meri uslovljena razvojem Interneta i informatičkim mogućnostima same 
kompanije. Na tržištu postoji mnogo različitih softverskih i hardverskih rešenja, ali ova 
rešenja su mahom skupa i potrebno je izuzetno veliko znanje za njihovo korišćenje. 
Neke kompanije jednostavno nemaju ova sredstva i samim tim su hendikepirane u 
nastojanju da se uključe u proces globalizacije. Po jednoj definiciji globalizacija je 
proces kroz koje se regionalne i nacionalne ekonomije integrišu kroz međunarodne 
sisteme trgovine, transporta, bankarstva i sl. Pomoću transfera tehnologije, tehnologija 
se širi u svetu. Najbolji primer ovoga jeste Internet, koji je prisutan skoro u svakoj 
zemlji. Danas postoji veliki promet robe i dobara, tako da se u jednoj prosečnoj zemlji 
može naći roba koja nije prirodna za to podneblje i to po niskoj ceni. Organizacija 
multinacionalnih korporacija postaje posebno polje interesovanja za mnoge nauke, 
takođe je u poslednjih nekoliko decenije interesovanje za razvoj malog i srednjeg 
biznisa pojačano. Razlog je očigledan, male kompanije imaju izuzetno veliku agilnost u 
odnosu na velike kompanije, a velike kompanije imaju potrebu za nekim promenama 
paradigmi sa ciljem postizanja veće fleksibilnosti. Upravo je ovo bio veliki podstrek da 
se počne razmišljati u smeru većeg stepena iskorišćena informacionih sistema jer se uz 
dobru informaciju mogu zaraditi ili uštedeti velika materijalna sredstva. 

Virtuelni timovi. Neke promene paradigme poslovanja su popularizacija i razvoj 
timskog rada, timski rad je po svojoj prilici najbolje rešenje za postizanje rezultata u 
relativno kratkom roku. Međutim, u domenu internacionalnog poslovanja timski rad ima 
veliku manu, a to je da se od članova zahteva da budu na jednoj geografskoj lokaciji. Za 
mnoge intemacionalne korporacije i manje kompanije koje su uključene u proces 
međunarodnog poslovanja ovo nije prihvatljivo rešenje [230]. 

Mali broj kompanija zaista uspostavlja idealne strukture kompletno bazirane na timu, u 
ovom scenariju. U praksi, većina lilijala se mkovodi uz pomoć tradicionalnih, 
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hijerarhijskih sistema i akcija zemalja domaćina, a ne sistema timova sa delegiranom 
moći. Bez obzira na to, menadžeri zemlje domaćina i njihove filijale zauzimaju važne 
pozicije unutar šire mreže proizvodnih sistema kompanije. Zato je koordinacija 
različitih interesa osnovna stvar i ovi menadžeri i njihove jedinice treba da reaguju 
jedna na drugu na način sličan timskom radu kada se radi o kolaborativnim mrežama 
međusobnih odnosa u intemacionalnim aktivnostima. Broj Internet korisnika je veći od 
dve milijarde ljudi, što znači da postoji jako velika osnova za uvođenje Intemeta u sfem 
svakodnevnog poslovanja. Ljudi su već navikli na Intemet i tehnologije koje ovaj servis 
nudi, a sa druge strane, stalni razvoj tehnologije poboljšava kvalitet iste i čini je 
sigumijom za korišćenje. Kamen temeljac virtualnog tima jeste Internet i mnoge 
tehnologije koje su u bliskoj vezi sa ovim fenomenom. Rad van kancelarije postaje 
svakodnevica mnogim ljudima, mogućnost da se dobiju ažurne informacije sa mesta 
njihovog nastanka uz pravilnu interpretaciju eksperta diže poslovanje na jedan sasvim 
novi nivo. U prethodnom periodu skupljanje i obrada podataka bili su skupi procesi koji 
su uključivali posredovanje operatera za unos podataka i stmčnjaka za automatsku 
obradu podataka. Danas ovo više nije slučaj, podatak može ući u infonnacioni sistem na 
mestu na kojem nastaje bez mogućnosti greške ili sa malom mogućnošću. Uz eksperta 
koji se nalazi na licu mesta dešavanja nekog procesa, moguće je dobiti, pored čvrstih 
podataka, i ekspertizu koja je mnogo kvalitetnija jer nema entropije podataka. 

Paradigma otvorenog koda. Primer ove tvrdnje su vlade Nemačke i Velike Britanije. 
Ove zemlje su usled pritisaka da smanje troškove prešle na softver otvorenog koda. To 
konkretno znači da su ove vlade odlučile ne samo da smanje troškove, već i da aktivno 
učestvuju u razvoju IT rešenja [196]. Naravno, jako je teško porediti javni i privatni 
sektor, ali princip je isti, svi akteri zahtevaju manje troškove, veću sigumost IT 
proizvoda i sl. U ovom primem nemamo direktnu vezu sa fenomenom „cloud 
computing“-a, ali sistem otvorenog koda se isto može smatrati novom paradigmom koja 
je u direktnoj suprotnosti sa važećom paradigmama komercijalnog softvera. Otvoreni 
kod će se najviše vezivati za individualne korisnike i male kompanije, sa druge strane 
sve kompanije koje žele da postignu konkurentsku prednost preferiraće softverska 
rešenja iz domena „ cloud computing“-a. Veliki komercijalni proizvođači softvera već 
danas nude neka svoja rešenja iz domena „cloud computing“-a, a ne napuštajući sistem 
razvoja ,,klasičnog“ softvera. Tako da je moguće da će se i dalje nuditi softver kao do 
sada, sa tom razlikom što će se unapređenja i revizije ređe pojavljivati. 

Što se tiče virtualnih timova, „ cloud computing“ će verovatno imati sve veći uticaj na 
dalji razvoj ovog vida timskog rada. Međutim, biće potrebno mnogo vremena kako bi se 
virtualni timovi u potpunosti afirmisali. Fleksibilnost je postala nova poslovna 
paradigma, a „cloud computing“ i virtualni timovi imaju tu moć da izađu u susret novim 
izazovima tržišta. U prošlosti „ mainframe“ arhitektura je jednostavno napuštena zbog 
tehničkih ograničenja i inferiomosti u odnosu na sisteme koji su sami obrađivali 
podatke. Samim tim možemo zaključiti da nam u bliskoj budućnosti predstoji oštra igra 
konkurenata, što je za korisnike dobro zbog veće palete softverskih rešenja. 

Kolaboracija kao nova poslovna paradigma. Kolaboracija je rekurzivan proces u 
kome više ljudi ili organizacija sarađuju da bi ostvarili zajednički cilj [186]. Po svojoj 
prirodi kolaboracija je kreativan proces, koji se realizuje deljenjem znanja, učenjem i 
izgradnjom konsenzusa. Kolaboracija ne zahteva mkovođenje, već se bolji rezultati 
postižu decentralizacijom i jednakošću. Pod kolaboracijom se podrazumeva i bogatstvo 
sadržaja sa kojima objekti (inteligentni uređaji, ljudi i kompanije) mogu zajedno stvarati 
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nove vrednosti, korišćenjem Internet tehnologija [93]. 

Tradicionalna transakciona teorija poslovanja podrazumeva obaveznu razmenu dobara 
ili servisa između učesnika. U tradicionalnoj komandnoj i kontrolnoj poslovnoj 
hijerarhiji, gde su procesi upravljali ljudima, posao je bio podeljen na manje delove za 
čiju realizaciju su bili određivani pojedinci ili grupe zaposlenih. Sada, u vreme digitalne 
ekonomije, radnici znanja (knowledge workers ) upravljaju poslovnim procesima, 
konstantnom manipulacijom podataka i razmenom informacija direktno sa ostalim 
radnicima, nezavisno od tradicionalne menadžerske strukture. To stvara konstantni nivo 
pseudotransakcija između zaposlenih, sa partnerima, potrošačima, snabdevačima, 
konkurencijom i određenim subjektima okruženja, pri čemu ne postoji razmena ni roba 
ni servisa. To što nema razmene roba ili servisa, ne umanjuje značaj ovih interakcija za 
donošenje validnih odluka ili upravljanje poslovnim procesima. Interakcija među 
ljudima, da bi se postigao zajednički cilj, bez razmene roba ili usluga, može se definisati 
kao kolaboracija. U modemim organizacijama kolaboracija se podstiče, upravlja i prati 
infonnacionim tehnologijama. Danas, zahvaljujući tehnologijama grupisanim oko 
semantičkog veba 2.0, može se postići visok nivo cfikasne kolaboracije, unutar 
kompanije i sa svim ostalim partnerima. Analizom tipova kolaboracije uočava se pet 
kaskadnih nivoa kolaboracije, koji su prikazani na slici 24. 
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Slika 24. Tipovi kolaboracije 

SOA I WEB 2.0 - kao paradigma e - poslovanja. Ideja kolaboracije donosi suštinske 
i globalne promene načina poslovanja [45]. Potrebe savremenog poslovanja čine da 
zahtevi za kolaboracijom prevazilaze mogućnosti zatvorenih informacionih sistema, 
koji su dizajnirani i realizovani u vreme kada su tehnološka rešenja nametala parcijalno 
tretiranje poslovnih procesa. Upravljanje poslovnim procesima (BPM - Business 
Process Management) jcstc metodologija upravljanja resursima kompanije i definisanjc 
interakcija između resursa, u cilju generisanja servisa ili proizvoda prema potrebama 
klijenata. Upravljanje poslovnim procesima je sveobuhvatan i celovit pristup 
unapređivanju poslovanja i podešavanja organizacije zahtevima tržišta. Upravljanje 
poslovnim procesima predstavlja koherentan pristup poslovanju tako što obezbeđuje da 
postoji samo jedan poslovni proces za zadovoljavanje određene poslovne potrebe i samo 
jedan servis za podršku tog poslovnog procesa. Taj servis se može izvršavati u 
mrežnom okruženju, tj. u svim organizacionim delovima kompanije. U skladu sa tom 
servisno orijentisanom paradigmom, upravljanje poslovnim procesima može se 
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posmatrati kao jedna kompozitna aplikacija, koja orkestrira poslovnim procesima kao 
servisima i na taj način integriše i automatizuje poslovanje. Bazirana na standardima i 
principima najbolje prakse, servisno orijentisana paradigma omogućava sveobuhvatno, 
integrativno unapređivanje upravljanja poslovnim procesima. Bez primene servisno 
orijentisane paradigme moguće je postići samo parcijalna organizaciona ili tehnološka 
unapređenja, ali infrastruktura kompanije i dalje sporo reaguje na promene, nije 
fleksibilna i skupa je. Kamen temeljac uspešne primene servisno orijentisane 
paradigme, svakako, predstavlja poznavanje poslovne problematike u određenom 
domenu. Pored tih bazičnih znanja, neophodno je i poznavanje specifičnih znanja iz 
informacionih tehnologija, pre svega sa aspekta primene servisno orijentisane 
arhitekture [124]. 

Projektovanje sistema za upravljanje poslovnim procesima jedan je iterativan postupak 
u kome se poslovni procesi, njihove karakteristike i efekti prate tokom celog ,,života“ 
procesa, u svim organizacionim celinama kompanije. Potpuno razumevanje poslovne 
strategije kompanije kao i razumevanje metoda i resursa iz IT domena, preduslovi su 
uspešnog projektovanja i realizacije sistema za upravljanje poslovnim procesima. Iako 
su SOA i Web 2.0 nastali u IT domenu, oni danas predstavljaju paradigmu za korišćenje 
distribuiranih mogućnosti kompanije radi postizanja poslovnih ciljeva, na 
konzistentan način, uz mogućnosti merenja postignutih efekata. Polazeći od 
dekompozicije poslovanja, prikazano radno okruženje omogućava orkestraciju novih i 
postojećih servisa u poslovne procese. Servisno orijentisano radno okruženje koristi se 
kao platforma za razvoj novih, dinamičkih poslovnih aplikacija, ali istovremeno 
omogućava inkrementalno unapređenje ,,nasleđenih“ aplikacija, čime se značajno 
čuvaju prethodne investicije. Integracija servisno orijentisane arhitekture i semantičkog 
veba 2.0 sa poslovnim procesima i metodama poslovne inteligencije omogućava 
efikasno i fleksibilno reagovanje na promene tržišnih uslova, zahteve potrošača i 
izazove konkurencije. Konvergencijom SOA i veba 2.0 stvorena je fleksibilna i 
kolaborativna softverska arhitektura, novi pristup, koji omogućava masovno učešće svih 
zainteresovanih u procesu unapređivanja i usavršavanja poslovanja [124]. 

Sva moderna softverska rešenja podrazumevaju primenu servisno orijentisane 
arhitekture i semantičkog veba 2.0. Njihova snažna povratna veza na poslovanje 
kompanija čini ih važnim gradivnim elementima referentnog modela elektronskog 
poslovanja. Fleksibilnost servisno orijentisane arhitekture i kolaborativnost semantičkog 
veba 2.0 predstavljaju novo radno okruženje, koje omogućava efikasno korišćenje 
najnovijih tehnologija, kako informatičko-komunikacionih, tako i tehnologija iz domena 
poslovanja. Ova paradigma omogućava fleksibilno usklađivanje tehnoloških i poslovno- 
upravljačkih funkcija kompanija, i čini kompanije otvorenim za interaktivnu 
komunikaciju, ne samo sa kupcima i partnerima, već sa svima koji imaju pristup 
Intemetu. Informacioni sistemi realizovani na principima servisno orijentisane 
arhitekture i semantičkog veba 2.0 omogućavaju korišćenje potencijala najnovijih 
tehnologija u cilju realizacije ekonomskih i poslovnih benefita [124]. 

4.2.1 Strukturalne metodologije 

Razvoj informacionog sistema prema principima životnog ciklusa podrazumeva takav 
proces koji teče kroz niz sukcesivno procesnih faza, gde završetkom jedne faze 
započinje naredna i gde između susednih faza postoji snažna iterativna interakcija. Ovo 
je proces kojim sistem analitičari, softver inženjeri i programeri izgrađuju informacioni 
sistem. To je, takođe, paradigma i sredstvo upravljanja ovako složenim, dugotrajnim i 
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skupim projektima. Prilazi i metodologije razvoja informacionih sistema često se 
mešaju sa životnim ciklusom. Neretko se postavlja pitanje: ima li razlike? Neki eksperti 
tvrde da su prilazi i metodologije razvoja informacionih sistema supstitut za životni 
ciklus. Drugi misle da su prilazi i razvojne metodologije, više-manje namenjeni da 
upotpune, metodološki razjasne i omoguće efikasniji razvoj infonnacionog sistema i 
smatra se da principi i filozofija životnog ciklusa informacionog sistema nisu iščezli, da 
su još uvek veoma aktuelni jer informacioni sistemi nastaju, razvijaju se, sazrevaju, ali i 
nestaju. Oni se, dakle, u okviru ovakvog stanovišta mogu razvijati različitim prilazima i 
metodologijama. Prilazi i metodologije, o kojima će u ovom radu biti reči, struktumi su, 
objektni i agilni [228]. 

Jedna od najvažnijih metodologija razvoja informacionog sistema je stmktuma 
metodologija životnog ciklusa, koja je usredsređena na stmkturni prilaz. Osnova ove 
metodologije je stmkturna sistem analiza [5], dizajn, implementacija i stmkturne 
metode, tehnike, CASE alati. Najpoznatije u literaturi i u praksi najčešće korišćene 
stmkturne metodologije su: 

• SADT (Striictured Analvsis and Design Techniques) Whitten, Bentley, (1998), 

• SSADM (Structured Analvsis andDesign Method) Whitten, J., Bentley, L.D. 
(1998), 

• ISAC (Information System Work and Analysis of Change) Lundberg, (1981), 

• SSA (StructuredSystems Analvsis), Gane, C, Sarson, T. (1979), 

• IE (Information Engineering) Martin, J.(1990), 

• RAD (Rcipid Application Development) Gane, C. (1990). 

4.2.1.1 Rapid Application Development (RAD) 

RAD ili Metodologiji brzog razvoja informacionog sistema ima sledeće korake [41]: 

• uspostavlj anj e upravlj ačke stmkture proj ekta; 

• identifikovanje, analiza i specifikacija informatičkih zahteva i odgovora na 
infonnacione zahteve; 

• logička analiza i modelovanje sistema; 

• logičko modelovanje podataka; 

• projektovanje relacionih baza podataka; 

• transformacija logičkog modela u fizički; 

• specifikacija logičkih procedura obrade podataka; 

• implementacija sistema. 

Uspostavljanje upravljačke strukture. Uspostavljanje upravljačke stmkture projekta 
nužno je zbog problema sa multiorganizacionim sistemima. Projekti razvoja novog ili 
modifikacije postojećeg sistema skoro uvek izazivaju radikalne promene u više 
organizacionih jedinica i mogu biti uzrok mnogih konflikata i otpora. Većina ljudi u 
organizaciji ne voli promene, čak i ako su one veoma korisne za organizaciju kao 
celinu, odeljenja, radne gmpe i pojedince. Izvori konflikata i otpori mogu biti različiti. 
Najčešće se, međutim, tiču problema opravdanosti ulaganja i preduzimanja ogromnih 
napora da se novi sistem razvije jer menadžeri su skloni tvrdnji da takva ulaganja i 
napor nisu srazmerni korisnosti koju sistem donosi, jedni se boje da će novi sistem 
smanjiti njihovu moć, a dmgi da će njihov posao postati teži, dosadniji, pa čak da će i 
nestati. Za savladavanje otpora i prevazilaženje konflikata zahteva se značajno vreme, 
pa je to često i razlog zašto razvoj informacionog sistema dugo traje. Ljudi koji čine tim 
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za razvoj informacionog sistema, stručnjaci za informatičke tehnologije, imaju pred 
sobom dve ozbiljne prepreke u efikasnom suzbijanju otpora i rešavanju konflikata. Prva 
je ta što oni ne poznaju dovoljno oblasti u kojima se otpori i konflikti pojavljuju, imaju 
pomanjkanje kompetencija. Druga, nemaju adekvatna ovlašćenja i autoritet u odnosu na 
ove ljude. Iz ovih razloga je neophodno na vreme spoznati da ključ uspeha brzog i 
efikasnog razvoja informacionog sistema leži u načinu upravljanja celokupnim 
projektom. Osoba koja će stati na čelo projekta mora biti iz samog vrha menadžmenta 
organizacije, koja ima odgovornost za uspeh projekta i autoritet nad delokrugom 
projekta, politikama koje će podržavati razvoj projekta i omogućiti organizacione 
promene koji će razvoj i implementacija projekta implicirati. Menadžer koji dobija 
ovakvu ulogu poznat je kao „izvršni sponzor“, i on uspostavlja odgovarajuću 
upravljačku strukturu projekta. 

Specifikacija zahteva. Identifikovanje, analiza i specifikacija infonnacionih zahteva i 
odgovora na informacione zahteve, analiza i definisanje informacionih zahteva drugi je 
deo jedinstvene metodologije brzog razvoja informacionog sistema. Metod koji se 
koristi u identifikaciji zahteva je metod intervjua. Za razliku od tradicionalnog pristupa, 
koji je akceptirao seriju nezavisnih, pojedinačnih intervjua, ovde je reč o primeni 
tehnike grupnih intervjua, gde jedan ili više analitičara intervjuiše ,,komitet“ za 
upravljanje projektom i reprezente korisnika u isto vreme. Sprovođenje niza i velikog 
broja pojedinačnih intervjua, od strane većeg broja analitičara, prouzrokuje više teškoća, 
među kojima su najznačajnije: 

• proces intervjuisanja dugo traje, izostaje komunikacija između intervjuisanih i 
troškovi su veliki; 

• stavovi intervjuisanih u vezi sa istim problemima mogu biti različiti i veoma je 
teško pomiriti izražene razlike; 

• između različitih organizacionih jedinica često se javljaju različiti ciljevi i 
zahtevi koji su kolitični, uvek za posledicu imaju konflikte i otpore koje je 
veoma teško rešiti odnosno ukloniti. 

Metod grupnog intervjua veoma efikasno rešava ove vrste problema. Grupni intervjui 
imaju teorijsko uporište u teoriji grupne dinamike. Suština pristupa grupne dinamike se 
može iskazati u sledeće četiri paradigme: 

• Sastanak je najproduktivniji ako je vođen od moderatora, koji je „prirodni 
poslužitelj“ grupe, koji vrednuje i distribuira ideje. Njegova je odgovornost da 
pomogne grupi, da njihovu energiju usredsredi na zadatak sa predlaganjem 
metoda i procedura, zaštitom članova grupe od ataka i stvaranjem šanse svakom 
da u radu učestvuje. 

• Najproduktivnije grupno odlučivanje je konsenzus, u kojem se svako oseća 
,,pobednikom“, ili ako nije dobio tačno ono što je želeo, prihvata odluku bez 
kompromisa ili nekog ,,debelog“ ubeđivanja. 

• Grupna sesija je najproduktivnija ako se pridržava plana, koji je grupa prihvatila 
konsenzusom; 

• Grupna sesija je najproduktivnija ako se rezultati diskusije prikazuju na zidu, 
kako se oni pojavljuju, gde ih svako može videti. Displej se često označava kao 
„grupna memorija“, a član koji kreira displej igra ulogu ,,zapisivača“. 
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Grupni intervju podrazumeva zajednički sastanak reprezentanta korisnika i 
projektantskog tima u istoj sobi i u isto vreme, koji kontinuirano drže radnu sesiju 
(■ workshoop ) koja traje najmanje jedan, obično tri, a ponekad i pet dana. Uspeh ove 
tehnike identifikacije informacionih zahteva značajno je zavisan od načina vođenja 
sesije grupnog intervjua, koja treba da bude vođena, prema indikacijama uspešnosti iz 
dosadašnje prakse, osobom koja nije opterećena parcijalnim interesima konačnih izlaza 
projekta, neko ko ima isključiv cilj da što pre i na što efikasniji način dođe do 
konsenzusa o koherentnom zajedničkom skupu zahteva. Glavna korist upotrebe ovog 
metoda je veoma kratko vreme izvršenja faza identifikacije zahteva. Ako se konflikti 
pojave oni mogu biti otvoreno i neposredno raspravljani i razrešeni veoma brzo. 
Posebno značajna korist se ispoljava u mogućnosti da korisnici participiraju u 
donošenju odluke o delokrugu i prirodi sistema koji se razvija za njih, i koji svoj stav 
izražavaju sledećom tvrdnjom: „Ovo je naš sistem, a informatičko osoblje nam pomaže 
da ga izgradimo“ Gane, C. (1990). Svaki projekat razvoja informacionog sistema, 
tokom intervjua uključuje nekoliko grupa radnih sesija. To su po Gane, C. (1990): 
strategijska sesija - sa zadatkom determinisanja delokruga projekta, ciljeva, resursa; 
podaci/procesi sesija - sa zadatkom izgradnje ili pročišćavanja dijagrama toka podataka 
i modela podataka i definisanja logike poslovne politike; ekrani/izveštaji sesija - sa 
zadatkom da se definiše interaktivni dijalog i izgledi izveštaja. Učesnici intervjua su 
predstavnici korisnika. 

Analiza i modeliranje. Ovim korakom metodologije modeluju se procesi sistema. 
Osnovni ciljevi koji se postižu putem upotrebe tehnike dijagrama toka podataka su: 

• definisanje granice sistema i poslovnog domena koji isti pokriva; 

• veoma jednostavna i za korisnika krajnje prihvatljiva prezentacija sistema, 
potpuno razumljiva za poslovni svet koji nije familijaran sa informacionim 
tehnologijama; 

• prikaz memorisanih podataka (datoteka, evidencija, kartoteka, arhiva) u sistemu 
i procesa koji te podatke transformišu, kao i njihov međusobni odnos (relacije). 

Logičko modelovanje podataka. Logičko modelovanje sistema u najužem smislu 
podrazumeva izradu DTP za određeno domensko područje i takozvani First-Cut („prvi 
presek“) modela podataka [31]. Bilo bi metodološki konzistentnije u pojam logičke 
analize i modelovanja sistema uključiti i entitet- odnos analizu (E-O-M) podataka i 
specifikaciju logičkih jedinica procedura obrade. Prema tome, logičku analizu i 
modelovanje sistema možemo shvatiti kao proces od dva koraka. 

Relaciona analiza podataka se preduzima sa ciljem da se projektuje logička struktura 
baze obeležja relacionog modela baze podataka, odnosno da se dobije struktura n 
međusobno povezanih dvodimenzionalnih tabela koje će sačinjavati jednu bazu 
podataka. Metod kojim se takva struktura dobija poznat je pod nazivom metod 
normalizacije. Preimplementaciono ,,sređivanje“ modela podataka odnosi se na njegovo 
prilagođavanje zahtevima kao što su prihvatljivo vreme pristupa i pretraživanja, 
prihvatljiv memorijski prostor neophodan za smeštaj baze podataka. Spajanje relacija 
može biti uputno i korisno realizovano u cilju da se uštedi vreme i unapredi integralnost 
celine. Dizajner baze podataka pre nego što nacrta E-R-M, obaviće konsultacije po ovim 
pitanjima i zajedno sa administratorom baze podataka izvršiti konsolidaciju modela. 

Specifikacija procesiranja. U specifikacije logičkih procedura obrade podataka 
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detaljno se specificiraju detalji definisanih jedinica logičkih procedura. Specifikacija 
obavezno sadrži sledeće elemente, Gane, C. (1990): 

• Isečak iz sistemskog DTP, koji pokazuje gde se ova proceduralna jedinica nalazi 
u ostatku sistema; 

• Detalje o tabelama (relacijama) kojima se pristupa ovom jedinicom procedure; 

• Izgled ekrana ili izveštaja koji su uključeni u jedinicu procedure; 

• Napomene o logici i sadržaju procedure koja treba da bude implementirana, 
pisane u struktumom engleskom ili nekoj drugoj nedvosmislenoj formi. 

Pošto su sve specifikacije jedinica procedure urađene, programeri mogu veoma brzo 
izgraditi prototip ili izvesti direktnu celovitu implementaciju u nekom programskom 
jeziku, odnosno alatu. 

Implementacija. Implementacija sistema i razvoj softverskog dela sistema poslednji je 
korak RAD metodologije [41]. Neproceduralnim alatima i softverom za upravljanje 
bazama podataka kao što su ORACLE, INFORMIX, DB-2, PROGRES, FOCUS, 
aplikacije se razvijaju veoma brzo zahvaljujući, pre svega, tome što oni obezbeđuju lako 
ili brzo definisanje ekrana i editovanje podataka koji se unose putem ekrana, računanje i 
manipulaciju nizovima, pretraživanje i ažuriranje baza podataka (SQL standardi), 
generisanje planiranih izveštaja i ekranskih displeja, sistemsko generisanje aplikacija. 
Većina ovih jezika su „klasterizovani subjezici“, jer obezbeđuju subjezike za različite 
funkcije, na primer: subjezik za definisanje ekrana, drugi za pretraživanje baza podataka 
itd. 

4.2.2 Objektne metodologije 

Najpoznatije u literaturi i u praksi najčešće korišćene objektne metodologije su: 

• OOAD ( Object Oriented Analysis and Design ) Martin, J., Odell, J.J. (1992), 

• OOADA ( Object Oriented Analvsis and Design) Booch, G. (1994), 

• OMT (Object Modeling Technique) Rumbaugh, J. (1991) 

• OOA/OOD ( Object Oriented Analvsis/Object Oriented Design) Yourdon, E. 
(1995) 

• RUP (Rational Unified Process) Jacobson, I. et.al (1999) 

4.2.2.1 Rational Unified Process (RUP) 

Rational Unified Process (u nastavku RUP) predstavlja objektno orijentisani proces za 
izradu softvera [107]. Ovaj proces je zasnovan na pristupu baziranom na disciplinama, u 
okviru kojih se vrši raspodela poslova i odgovornosti na članove razvojnog tima i ostale 
učesnike u procesu razvoja softvera. Osnovna namena RUP-a jeste proizvodnja 
visokokvalitetnog softvera, kao krajnjeg rezultata projekta, koji zadovoljava potrebe 
korisnika, a u okviru planiranog budžeta i vremena. RUP je framevvork (radni okvir) 
koji je moguće prilagođavati potrebama organizacije koja ga usvaja. On sadrži skup 
dobro definisanih preporuka i uputstava za uspešan razvoj softverskog proizvoda. 
Upravo radi toga, kod navođenja definicije RUP-a izbegava se izraz metodologija, koji 
predstavlja znatno čvršći set pravila od navedenog izraza framework. Međutim, 
pojedinačnim podešavanjem RUP-a organizacija može da kreira svoj metodološki okvir, 
a u okviru njega i čvrsta pravila izgrađena na osnovu datih preporuka i uputstava. 

U izgradnji informacionog sistema RUP preporučuje korišćenje raznih metoda i tehnika, 
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ali su svakako najdominantnije tehnike modelovanja korišćenjem Unified Modeling 
Language -а (u nastavku UML), tj. jedinstvenog jezika za modelovanje. Za RUP se čak 
može reći da predstavlja uputstvo za korišćenje UML-a. RUP je inicijalno zamišljen za 
razvoj velikih projekata, ali je svoju primenu našao i u srednjim i malim softverskim 
projektima. Softverski timovi, naročito veliki, znatno unapređuju svoju produktivnost 
korišćenjem RUP-a. RUP omogućuje svakom članu razvojnog tima lak uvid u bazu 
znanja, zasnovanu na uputstvima, obrascima i uputstvima za korišćenje alata, što 
predstavlja podršku u svim kritičnim razvojnim aktivnostima. To doprinosi da svi 
članovi razvojnog tima, bez obzira na aktivnosti koje obavljaju, koriste zajedničku 
metodologiju, jezik i pogled na to kako treba razvijati softverski proizvod. Principi na 
kojima je zasnovan RUP omogućuju razvoj kvalitetnih softverskih proizvoda i 
postavljanje metodoloških koraka kojima će se realizovati kompletne preporuke i 
uputstva zasnovani na dolenavedenim principima. 

Iterativan razvoj. Klasični proces razvoja softvera zasniva se na modelu vodopada, 
koji je ranije opisan. Alternativa modelu vodopada jeste iterativno-inkrementalni model 
razvoja softvera. Korišćenjem ovoga modela dolazi se do relativno brze realizacije 
početne verzije softvera koja se razvija dodatnim iteracijama. Takođe, integrisanje i 
testiranje softvera obavlja se češće, te se na taj način postiže smanjenje rizika. Što je 
razlika između trenutka otkrivanja greške i trenutka nastanka greške veća, to je njeno 
otkrivanje i otklanjanje teže i skuplje. Iterativni proces se sastoji iz više sekvencijalnih 
procesa zasnovanih na modelu vodopada. Time je vremenska dimenzija izmeštena u 
odnosu na sadržajnu dimenziju, pa je vreme između potencijalnog nastanka i otkrivanja 
grešaka značajno skraćeno. Kao prednosti iterativnog razvoja mogu se navesti sledeće: 

• Greške učinjene u razvoju ranije se identifikuju i moguće je uspešnije reagovati; 

• Omogućava se korisnička povratna sprega; 

• Razvojni tim je primoran da se fokusira na ona pitanja koja su najvažnija za 
projekat; 

• Kontinuirano i iterativno testiranje pruža objektivan uvid u status razvoja; 

• Nepravilnosti tokom analize zahteva, dizajna i implementacije otkrivaju se 
ranije; 

• Tim za testiranje je uključen tokom celog životnog ciklusa projekta; 

• Tim usavršava naučene lekcije i tako može neprekidno da unapređuje proces 
razvoja. 

Upravljanje zahtevima. Prateći rezultate Standish grupe dolazi se do spoznaje, da je u 
37% slučajeva razlog za neuspeh projekata vezan za informacione zahteve. Nedostatak 
korisničkih zahteva predstavlja razlog neuspeha projekata u 13% slučajeva, nepotpuni 
zahtevi i specifikacije u 12% slučajeva, a promena zahteva i specifikacija takođe u 12% 
slučajeva. Dodajući navedenim podacima činjenicu da su troškovi otklanjanja grešaka 
nastalih u oblasti zahteva izuzetno visoki, iako ih iterativan pristup značajno umanjuje, 
nameće se zaključak da se zahtevima ne posvećuje dovoljna pažnja u procesu razvoja 
infonnacionih sistema. Informacioni zahtevi predstavljaju inpute za dizajn sistema, 
testiranje sistema, kao i izradu korisničke dokumentacije. Greške u fazi analize zahteva 
pogubne su po uspeh projekta razvoja. Da bi se gorenavedeni procenti smanjili, 
potrebno je posvetiti značajnu pažnju pronalaženju, organizovanju, dokumentovanju i 
upravljanju zahtevima. RUP upravo to i radi kroz disciplinu zahteva čiji je cilj da opiše 
šta sistem treba da radi. Taj opis treba da bude prihvaćen, kako od strane korisnika, tako 
i od strane razvojnih inženjera. 
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Upotreba arhitekture zasnovane na komponentama. Vizuelizacija, specifikacija, 
konstrukcija i dokumentovanje softverskog sistema zahteva da sistem bude sagledan iz 
brojnih perspektiva. Svaka zainteresovana strana - stejkholder (analitičari, integratori 
sistema, testeri, projektni menadžeri, dizajneri) donosi različitu sliku projekta, i svaki od 
njih gleda sistem na različite načine, mnogo puta tokom života projekta. Arhitektura 
sistema je možda najvažnija podela koja se može koristiti da bi se upravljalo ovim 
različitim gledištima i na taj način kontrolisao iterativni i inkrementalni razvoj sistema 
tokom njegovog životnog ciklusa [106]. 

Arhitektura je prevashodno bitna za razvojni tim koji realizuje projekat, ali indirektno 
utiče i na zadovoljstvo krajnjeg korisnika. Arhitektura sistema obuhvata grupu 
značajnih odluka o: 

• Organizaciji softverskog sistema; 

• Izboru gradivnih elemenata i njihovih interfejsa, od kojih je sistem sastavljen; 

• Ponašanju gradivnih elemenata, određenom upravo njihovom saradnjom; 

• Kompoziciji strukturalnih i bihevioralnih elemenata u veće rastuće podsisteme; 

• Arhitektonskom stilu, koji objedinjuje gorenavedene odluke u jednu celinu. 

Razvoj baziran na komponentama (CBD - Component-Based Development ) je 
značajan pristup softverskoj arhitekturi jer omogućava ponovnu upotrebu, kao i 
specijalizaciju komponenata. Pored sopstvene izgradnje komponenata za ponovnu 
upotrebu moguća je upotreba komponenata i iz velikog broja komercijalno dostupnih 
izvora ( Microsoft Component Object Model - COM i Microsoft Foundation Classes - 
MFC, Common Object Request Broker Architecture - CORBA, Enterprise JavaBeans - 
EJB samo su neke od široko podržanih platformi na kojima je arhitektura zasnovana na 
komponentama ostvariva). Kombinujući iterativan razvoj sa arhitekturom zasnovanom 
na komponentama, svaki korak proizvodi izvršnu arhitekturu sistema, koja je merljiva, 
pogodna za testiranje i vrednovanje u odnosu na zahteve sistema. Na ovaj način se 
otvara mogućnost za konstantno napadanje ključnih rizika projekta. 

Vizuelno modelovanje. Model predstavlja pojednostavljenu sliku realnosti, koja 
kompletno opisuje sistem iz pojedinačnih perspektiva. U softverskom inženjeringu 
modeli se izgrađuju da bi se bolje razumeo sistem koji se modeluje. Kod izrade velikih 
sistema modelovanje pomaže njihovom razumevanju u potpunosti. Slobodno se može 
konstatovati da bi bez modelovanja automatizacija takvih sistema bila nemoguća. 
Činjenica da jedna slika govori više nego hiljadu reči poznata je odavno. Međutim, ono 
što je nedostajalo jeste standardizacija. UML kao jedinstveni jezik za modelovanje 
prihvaćen je od strane vodećih svetskih IT kompanija i nametnut je kao standard u 
softverskoj industriji. On služi za vizualizaciju, specifikaciju, konstrukciju i 
dokumentaciju sistema koji se izgrađuje. UML je omogućio svim članovima razvojnog 
tima da razgovaraju istim jezikom. Standardizacija je dovela do toga da se UML 
izučava u školama i fakultetima širom sveta, pa je time zamenjivost bilo kojeg člana 
razvojnog tima značajno olakšana. RUP i UML predstavljaju nerazdvojivu celinu. 
Vizuelno modelovanje podiže kvalitet procesa razvoja softverskog proizvoda, što je 
lako uočljivo preko sledećih karakteristika: 

• Use Case-o\i i scenarija nedvosmisleno dednišu ponašanje sistema; 

• dizajnje jasan i nedvosmislen; 

• nemodularne i nefleksibilne arhitekture su lako uočljive na nivou modela; 
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• različite perspektive i različiti nivoi detaljnosti mogu se koristiti u različiti 
situacijama; 

• otklanjanje nekonzistentnosti na nivou dizajna značajno olakšava 
implementaciju; 

• Use Case model i dizajn model stvaraju jasne inpute za testiranje; 

• korišćenje UML-a nameće standardizaciju u softverskoj industriji. 

Kontinuirana potvrda kvaliteta softvera. Softverski problemi su od 100 do 1000 puta 
skuplji kada se pronalaze i otklanjaju nakon uvođenja nego pre toga. Upravo zato, 
važno je kontinuirano proveravati kvalitet sistema sa posebnim akcentom na njegovu 
funkcionalnost, pouzdanost, aplikativne performanse i sistemske perfonnanse. 
Proveravanje funkcionalnosti sistema uključuje kreiranje testova, za svaki ključni 
scenario koji predstavlja neki aspekt željenog ponašanja sistema. Prilikom proveravanja 
funkcionalnosti sistema potrebno je evidentirati svaki scenario koji nije zadovoljio 
zahteve i pristupati njegovom osposobljavanju. Poštujući iterativan razvoj softvera tako 
je potrebno pristupati i testiranju, testirajući svaku iteraciju. Provera kvaliteta softvera 
pruža brojna rešenja ključnim uzrocima problema razvoja softvera: 

• procena statusa razvojnog projekta izrađuje se objektivno, jer se vrednuju 
rezultati testa; 

• objektivno procenjivanje otkriva nekonzistentnosti u zahtevima, dizajnu i 
implementaciji; 

• testiranje i vcrifikacija su usmereni na oblasti najvišeg rizika, te se na taj način 
uvećavaju kvalitet i efektivnost tih oblasti; 

• greške se otkrivaju rano, radikalno snižavajući troškove njihovog ispravljanja. 

Kontrola promena softvera. Ključni izazov prilikom razvoja softverskih sistema jeste 
usklađivanje rada razvojnih inženjera organizovanih u razvojne timove koji zajedno 
rade na više iteracija stvarajući softverski proizvod. Tokom razvoja novonastajući 
sistem se menja i razvija, a kontrola tih razvojnih promena nužna je za sprečavaje haosa 
u procesu razvoja. Usklađivanje aktivnosti, artifakta i uloga predstavlja ponovljivi 
workflow koji prati razvoj softvera kroz promene u procesu razvoja. Standardizacija 
workflow-a, sastavljenih od aktivnosti, artifakta i uloga, u procesu razvoja omogućuje 
praćenje promena, rano otkrivanje problema i brzo reagovanje u cilju njihovog 
otklanjanja. RUP razvoj informacionih sistema postavlja između dve dimenzije, 
vremenske i sadržajne. Vremenska dimenzija je podeljena u četiri faze: uvođenje, 
elaboracija, konstrukcija i tranzicija. Sadržajna dimenzija je podeljena u šest osnovnih i 
tri pomoćne discipline. U osnovne spadaju disciplina poslovnog modelovanja, disciplina 
zahteva, disciplina analize i dizajna, disciplina implementacije, disciplina testiranja i 
disciplina raspoređivanja. Pomoćne discipline su konfigurisanje i upravljanje 
promenama, upravljanje projektom i okruženje. Svaki element matrice RUP-a 
predstavlja kombinaciju elemenata statičke strukture RUP-a i vremenskog rasporeda 
istih. RUP je moguće posmatrati kroz dve dimenzije, kroz dinamičku, u kojoj se proces 
opisuje kroz životni ciklus razvoja proizvoda, i statičku, u kojoj se opisuju aktivnosti i 
rezultati aktivnosti podeljeni na uloge. 

Dinamička struktura RUP-a. RUP razvojni proces predstavlja kroz ciklus od četiri 
prethodno u tekstu navedene faze. Kao krajnji proizvod ovog ciklusa dobija se gotov 
softverski proizvod. Faze u procesu razvoja se ne izvršavaju u jednom prolazu, već se 
svaka od faza izvršava u nekoliko iteracija. RUP ne predviđa tačan broj iteracija. Do 
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tačnog broja iteracija po svakoj fazi dolazi se prilikom prilagođavanja RUP-a 
sopstvenim potrebama, tj. prilikom dcfinisanja konkretnog procesa razvoja. Svaka od 
utvrđenih iteracija donosi inkrement koji uvećava vrednost softverskog proizvoda u 
izradi. Kraj svake od faza smatra se ključnom tačkom u procesu razvoja. Ključne tačke 
predviđaju, na osnovu izvršene intergacije inkremenata realizovanih u posmatranij fazi, 
krajnje rezultate date faze. 

4.2.3 Dynamic systems development method 

DSDM [41] okvir može biti realizovan u okviru agilnog ili tradicionalnog razvojnog 
procesa. Poštovanje devet principa neophodno je za realizaciju DSDM [26], i ignorišući 
jedan od njih prekinuće sa filozofijom okružena i značajno će se povećati rizici projekta. 
Neki od koraka u zavisnosti od okruženja u kojem se primenjuje [199], mogu se 
modilikovati da bi odgovarali konkretnom projektu. Principi su sledeći: 

• aktivno uključivanj e korisnika j e imperativ; 

• članovi tima moraju biti osposobljeni i ovlašćeni za donošenje odluka; 

• fokus se stavlja na česte isporuke proizvoda; 

• sposobnost za primenu kod korisnika jesu kriterijumi za prihvatanje isporuka; 

• iterativno inkrementalni razvoj je obavezan; 

• sve promene u toku razvoja moraju biti reverzibilne; 

• proglašenje osnovnih zahteva visokog nivoa; 

• testiranje je integrisano u životni ciklus razvoja; 

• kolaborativni i kooperativni pristup u razvoju. 

DSDM kao framework je veoma dinamičan i modularan, slika 25. DSDM ne zahteva 
implementaciju celokupne projektne strukture, samo zahteva strogu poslušnost u 
primeni devet principa. Pored toga, svaki projekat menadžer može sprovesti 
odgovarajuće izmene procesa razvoja manje ili više agilne, u zavisnosti od situacije i 
ograničenja, a u mogućnosti je čak i da kombinuje sa drugim metodama razvoja. DSDM 
nema za cilj da reši sve probleme razvoja. Kada devet principa ne može biti realizovano, 
DSDM najverovatnije nije najbolji izbor. DSDM projekat se sastoji od sedam koraka 
fazama, slika 14. (pretprojektne aktivnosti, studija izvodljivosti, poslovna studija, 
iteracije funkcionalnog modela, iteracije dizajna, implementacija i postprojekat faza), u 
koje su organizovane ugrađene uloge sa odgovarajućim odgovomostima. DSDM je 
podržan od strane nekoliko kliučnih tehnika. Preporučene Core tehnike, opisane u radu 
jesu [105]: 

• vremenske kutije; 

• MoSColV pravila (Must, Should, Could, Want ); 

• pravljenje prototipa; 

• specijalizove radionice. 

Rukovodioci moraju da pre početka i tokom DSDM primene da ga imaju pod 
kontrolom, a ključni faktori koji moraju da budu pod kontrolom jesu: prihvatanje 
DSDM filozofije pre početka rada, odlučivanje o ovlašćenjima korisnika i programera 
unutar razvojnog tima, posvećenost višeg menadžmenta naručioca da obezbedi značajno 
učešće krajnjeg korisnika, inkrementalne isporuke, jednostavan pristup od strane 
programera krajnjim korisnicima, stabilnost tima, veštine razvojnog tima, veličina 
razvojnog tima, primenjene tehnologije. 
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CMM ( Capabilitv Maturitv Modefy, ISO 9001 i ekstremno programiranje savršeno su 
pogodni da se integrišu u DSDM implementacije jer se mnogi koncepti DSDM mogu 
poboljšati kao i upravljanje projektom. 

DSDM je napredan okvir nastao na osnovu najboljih praksi implementacije; prednosti 
su jednostavnost, proširivosti, što je dokazano u primeni, ali ne prestavlja rešenje za sve 
vrste projekata. Slabost DSDM je, kao i sa mnogim drugim strukturiranim pristupima, 
skup i spor prelazak koji zahteva značajan kulturni zaokret u bilo kojoj organizaciji. 
DSDM jasno se predstavlja kao najzrelija metoda agilnog razvoja. Nekoliko agilnih 
metodologije dele zajedničke osnove sa DSDM, na primer Scrum, koji kao DSDM, 
promoviše jačanje tima. Cristal metodologije zauzvrat pretpostavljaju da su kolekcija 
najboljih praksi, gde kao DSDM zahteva sveobuhvatan posao u primeni pokazujući 
svoju evolutivni karakter verzija njihovog okvira posle svake revizije od strane DSDM 
konzorcijuma [105]. 



Slika 25. Faze projekta [105] 

Spisak firmi koje koriste DSDM je dugačak, u njemu su i Shell, osiguravajuće kuće 
Loids banke, British Telecom, British Airvais, Deutsche Bahn, Hevlett-Packard, 
Renault, grad Los Anđeles i drugi. Mnoge druge organizacije već mogu koristiti 
DSDM, ali još uvek nisu spremne da se javno obavežu na DSDM, čak najveći prodavac 
softvera, Microsoft pozajmljuje ideje iz DSDM prilikom objavljivanja svog poluagilnog 
rešenja. Primena agilnih metodologija razvoja je veoma vidljivo u porastu. 

4.2.4 Extreme programing 

Prvi Extreme Programming projekat je startovan 06.03.1996. Extreme Programming je 
jedan od popularnijih metoda agilnih procesa [92]. Pokazala se uspešnom u mnogim 
kompanijama različitih veličina i industrija širom sveta. Extreme Programming je 
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uspešan pošto ima naglasak na zadovoljstvu naručioca. Umesto isporuke svega što se 
može zahtevati jednog dalekog dana u budućnosti, ovaj proces isporučuje softver onim 
redom kako proizvod nastaje. Extreme Programming ohrabruje developere da odgovore 
na promenu u zahtevima korisnika, čak i kasno u životnom ciklusu razvoja softvera. 
Extreme Programming naglašava timski rad. Rukovodioci, naručioci posla i developeri 
su podjednaki partneri u timu koji međusobno sarađuje. Extreme Programming 
implementira prosto i efikasno okruženje koje omogućava timu da bude produktivan. 
Tim se samoorganizuje oko problema koji treba rešiti na najefikasniji mogući način. 
Extreme Programming poboljšava projekat razvoja softvera u pet osnovnih pravaca: 
razvijenoj komunikaciji, negovanju jednostavnih rešenja uz povratne informacije, 
uzajamnom poštovanju učesnika i smelost. Developeri uključeni u Extreme 
Programming proces konstantno komuniciraju sa naručiocem i kolegama 
programerima. Oni ne usložnjavaju dizajn svojih rešenja i neguju čista i elegantna 
rešenja. Imaju povratnu spregu sa testiranja njihovih komponenata od početnog dana 
razvoja proizvoda. Isporučuju komponente naručiocu što je to pre moguće i na predloge 
odmah implementiraju izmene. Svaki mali uspeh produbljuje poverenje u doprinos 
svakog člana ekipe. Sa ovim osnovama developeri su u stanju da hrabro odgovore na 
promenljive zahteve i primenu nove tehnologije. 
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Slika 26. Extreme programming procesi 

Najistaknutiji aspekt Extreme Programming su jednostavna pravila. Ekstremno 
programiranje je poput rešavanja slagalice. Postoji mnogo malih komada. Pojedinačno 
komadi nemaju nikakvog smisla, ali tek kada se iskombinuju u zajedničku kompletnu 
sliku, može da se vidi šta u stvari predstavljaju. Pravila mogu izgledati čudno i možda 
čak i naivno na prvi pogled, ali su zasnovana na čvrstim vrednostima i principima. 
Pravila su ustrojena između članova tima, ali nisu krajnji cilj za sebe. Pravila definišu 
okruženje koje promoviše timsku saradnju. Jedanput postignut produktivan timski rad 
će imati kontinuitet i ako se pravila izmene da bi se rezultati uklopili u specifične 
potrebe naručioca. Slika 26. pokazuje kako su komponovana Extreme Programming 
pravila. Kupci su u ulozi partnera u procesu razvoja softvera, programeri aktivno 
doprinose u skladu sa novim iskustvima, dok su menadžeri u poziciji da se koncentrišu 
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na komunikaciju i izgradnju odnosa sa partnerima. Neproduktivne aktivnosti su 
odstranjene da smanje troškove, kao i frustraciju osoba koje su uključene u projekat. 

4.3 Servisno orijentisana arhitektura 

Uslužno orijentisana arhitektura (SOA - Service Oriented Architecture) je pojam koji 
označava infrastrukturalni model sistema čija se funkcionalnost zasniva na međusobno 
interoperabilnim ,,uslugama“, tj. fu nk cionalnim entitetima koji su u interakciji putem 
definisanih standarda [100]. Egzaktna definicija ne postoji, pa čak ni konsenzus oko 
toga da li pojam označava samo paradigmu, model sa svojstvima i smemicama kojih se 
pri implementaciji treba pridržavati ili čak strogo definisani skup tehnologija koje 
zajedno čine okosnicu uslužno orijentisane arhitekture. [11] 

Raghu R. Kodali, softverski inženjer iz kompanije Oracle i autor članaka za portal 
JavalVorld smatra da je SOA „...evolucija distribuiranog računarstva nastala na 
paradigmi zahtev/odgovor za potrebe sinhronih i asinhronih aplikacija. Poslovna logika 
aplikacije ili samo individualne funkcije objavljuju se u obliku usluga za korisnike, tj. 
klijentske aplikacije. Ključ sistema je svojstvo slabe povezanosti usluga, tj. nezavisnosti 
između interfejsa usluga i njihove implementacije. Kreatori aplikacija mogu izgrađivati 
aplikacije povezivanjem jedne ili više usluga bez znanja o njihovoj konkretnoj 
implementaciji.“ [93]. Ova definicija naglašava nekoliko ključnih karakteristika SOA 
sistema koje se najčešće spominju u svim definicijama - modularnost, distribuiranost i 
slaba povezanost [124]. 

Jedna od bolje sročenih definicija, koja se takođe često može naći u člancima 
povezanim sa SOA, jeste ona koju je dao Malte Poppensieker, profesor Trierskog 
univerziteta u Nemačkoj i koja glasi: ,,SOA je arhitektura u kojoj autonomne, slabo 
povezane i široko definisane usluge dobro definisanih interfejsa pružaju poslovnu 
funkcionalnost koja može biti na određeni način otkrivena i kojoj se može pristupiti 
kroz odgovarajuću infrastrukturu. Ovo omogućuje kako unutrašnju tako i spoljašnju 
integraciju, kao i fleksibilnu ponovnu iskoristljivost logike aplikacije logike kroz 
kompoziciju i rekompoziciju usluga.“ [57]. Ova definicija uz ponovno naglašavanje 
slabe povezanosti i integracije spominje i nekoliko dodatnih paradigmi koje se najčešće 
vežu uz pojam uslužno orijentisane arhitekture: svojstvo otkrivanja usluga, nužnost 
dobro definisanih interfejsa i pojam ponovne iskoristljivosti koji je okosnica 
funkcionalnosti uslužno orijentisane arhitekture. 

Za vizuelnu reprezentaciju SOA arhitekture često se koristi trougao „klijent-usluga- 
registar“ koji prikazuje visokoapstraktnu sliku glavnih odlika ovakvog sistema - objavu, 
pronalaženje, te povezivanje s traženom uslugom. U tom trouglu se jasno izdvajaju tri 
glavna učesnika SOA arhitekture: pružalac usluga, klijent usluga i registar usluga kao 
infrastrukturalna podrška koja omogućava pretragu usluga i daje konkretne infonnacije 
o njihovoj lokaciji i o tome kako im se može pristupiti. 

4.3.1 SOA - osnovna obeležja 

Servisno orijentisana arhitektura (SOA) predstavlja model korišćenja aplikacija ili 
softverskih modula u obliku informatičkih usluga, nezavisno od granica sistema u kome 
se te aplikacije nalaze. SOA sadrži komponente koje osiguravaju interoperabilnost i 
transparentnost aplikacija, nezavisno od njihove fizičke lokacije ili tehnologije 
implementacije. Ova tehnologija se bazira na korišćenju postojećih sistema i aplikacija i 
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nema tendenciju potpunog zamenjivanja starih, nasleđenih sistema. Koncept SOA u 
određenom smislu štiti postojeće investicije u softverske/hardverske platforme koje 
povezuje, olakšava izmene, i dalji razvoj usluga korišćenjem istih nasleđenih sistema. 

Tehnologija veb-servisa ( IVeb Services) je osnova arhitekture usmerene uslugama. Veb- 
servisi omogućavaju poslovnim aplikacijama zajedničke transportne protokole, 
programske interfejse i transakcione modele. Veb-servisi takođe omogućavaju 
korišćenje aplikacija unutar i izvan organizacije u kojoj se nalaze. Pomoću njih možemo 
relativno jednostavno uključiti spoljne partnere, dobavljače ili korisnike u inteme 
informacione sisteme. Osnovne poslovne prednosti korišćenja servisno orijentisane 
arhitekture pri dizajnu informacionih sistema su: brža i jeftinija izgradnja novih usluga 
ili aplikacija, manji troškovi održavanja sistema, viši stepen interoperabilnosti. 

Ono što tradicionalne računarske sisteme razlikuje od servisno orijentisanih sistema je 
to da se servisno orijentisani sistemi oslanjaju na pristup utemeljen na labavim vezama 
(loose/v coupled approach ili loosely coupled architecture), dok su se tradicionalni 
računarski sistemi oslanjali na čvrsto spregnute arhitekture ( tightlv coupled 
approach/architecture). Ovaj pristup čvrsto spregnutih arhitektura pokazao se 
neadekvatnim kod početaka razvoja intemetskog računarstva, kmtim za primenu u 
heterogenim i promenljivim uslovima elektronskog poslovanja, takođe i nepodesnim za 
stvaranje sigurnog i kvalitetnog kolaborativnog okmženja. 

Osnovna obeležja servisno orijentisane arhitekture su: 

• SOA čini virtualnu platfonnu servisa, dostupnu bilo kom informacionom 
sistemu; potpuno odvaja servise od njihove inteme implementacije; 

• svi interfejsi moraju da budu univerzalno dostupni svim ostalim elementima 
sistema; mogućnost njihovog pozivanja ne sme da zavisi od fizičkc lokacije i 
internih protokola ili infrastmkture komponente; 

• servisi mogu biti lokalni (unutar sistema) ili spoljašnji (izvan sistema); različite 
ravnopravne opcije pristupa servisima su: pristup iz iste aplikacije, pristup 
unutar istog sistema, pristup iz nekog dmgog sistema; 

• pomke kojima postavljamo zahtev prema veb-servisima moraju da budu opisne, 
a ne instmkcijske; šema pomke i sintaksa moraju da budu čvrsto delinisane i 
unapred dogovorene kako bi provajder servisa ispravno interpretirao zahtev za 
uslugom; 

• sistem mora da poseduje mogućnost proširenja i dovoljnu fleksibilnost kako bi 
omogućio brze promene funkcionalnosti bez dodatnog menjanja postojećih 
komponenata; promene uslovljene poslovnim okmženjem često se ne mogu 
dovoljno brzo implementirati u odgovarajuće informacione sisteme, a upravo 
SOA arhitektura treba da omogući potrebnu fleksibilnost; 

• sistem mora da omogući svojim korisnicima pronalaženje različitih servisa koji 
trenutno mogu da zadovolje njihove zahteve; 

• sistem mora da bude izgrađen na otvorenim standardima, jednostavnim 
protokolima i ne sme da ima jedinstvenu tačku ispada čitavog sistema; 

• arhitektura mora da omogući da sistem, a ne programer aplikacije, brine o 
sigurnosti i pravilima izvođenja transakcija; proizvođači SOA platformi nude 
većinu ovih elementa u obliku gotovih modula svojih proizvoda kako bi 
zadovoljili osnovne spccilikacije servisno orijentisane arhitekture. 
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Na osnovu ovoga može se zaključiti da SOA zahteva poštovanje sledećih koncepata: 

• interoperabilnost (interoperability) - e-servisi moraju između sebe biti 
kompatibilni; u SOA servis je delinisan kao funkcionalnost koju može izvesti 
komponenta nekog sistema i koju mogu da koriste drugi sistemi; u praksi to 
znači da jedan e-servis može da zahteva izvršenje jedne ili više operacija drugog 
e-servisa; takođe je potrebno da, ako korišćenjem nekog e-servisa dobijamo 
izlazne rezultate, ti rezultati budu u obliku koji je upotrebljiv za ostale e-servise; 

• ponovna upotreba (reusabilitv) - e-servise treba razvijati na modularan način, 
što znači da se njihovi delovi mogu ponovo upotrebiti u drugim e-servisima; 

• enkapsulacija (encapsulation) - korisnik ne treba da zna šta se dešava iza 
korisničkog interfejsa; preko jedinstvenog interfejsa može da se koristi više e- 
servisa, a specifikacije njihove implementacije korisniku treba da ostanu 
sakrivene; 

• skalabilnost (scalabilitv) - arhitektura mora da omogućava proširenja novim 
performansama, na hardverskom i softverskom nivou; npr. mogućnost 
proširivanja servera sa dodatnim performansama, module novim 
funkcionalnostima itd; 

• labavo povezani sistemi (looselv connected svstems) - taj koncept znači da mora 
postojati mogućnost povezivanja e-servisa, ali da svaki od njih predstavlja 
samostalnu jedinicu (funkcionalnost). 

Servisno orijentisana arhitektura definiše model interakcije između tri glavne 
funkcionalne jedinice: korisnika servisa, provajdera servisa i registra servisa, u kome 
korisnik servisa stupa u interakciju s provajderom servisa kako bi otkrio servis koja 
odgovara njegovim zahtevima putem registra za pretraživanje. 

SOA sadrži šest osnovnih elemenata u svom konceptualnom modelu [124]: 

• Korisnik servisa: Korisnik može biti aplikacija, neki drugi servis ili neka druga 
vrsta softverskog izvora kome je potreban servis; Korisnik servisa inicira zahtev 
za pronalaženje servisa i koristi servis; Lokacija servisa otkriva se ili 
pretraživanjem registra, ili, ako je poznata, korisnik može direktno da stupi u 
interakciju s provajderom servisa; 

• Povajder servisa: to je mrežna adresabilna komponenta koja prihvata i izvršava 
zahteve primljene od korisnika; on pruža precizan opis usluge i njenu 
implementaciju; Provajder servisa može biti mainframe sistem, komponenta ili 
neka druga vrsta softverskog sistema koji ispunjava zahteve korisnika za nekom 
uslugom; 

• Registar servisa: je direktorijum (imenik) kome se putem mreže može pristupiti i 
koji sadrži spisak i opis dostupnih servisa; njegova glavna funkcija je da 
skladišti i objavljuje opise servisa i da ih dostavlja zainteresovanim korisnicima. 

• Ugovor o servisu: je specifikacija načina na koji se vrši interakcija izmedu 
korisnika i provajdera servisa; sadrži informacije o formatu zahtev-odgovor 
(request-response) poruke, uslovima u kojima bi servis trebalo da se izvršava i 
kvalitetu servisa; 

• Ргоху servis (service ргоху ): provajder servisa može postaviti ргоху servis preko 
koga korisnik servisa pristupa veb-servisima; Korisnik izvršava zahtev za 
servisom pozivom API funkcije na ргоху- ju; Ргоху servis pronalazi ugovor o 
servisu i podatke o provajderu servisa u registru; on tada u ime korisnika šalje 
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zahtev za veb-servisom provajderu servisa i povezuje se sa servisom. 

• Zakup servisa: svaki put kada korisnik uputi zahtev za veb-servisom i ostvari 
kontakt sa njim, vreme koje mu se dodeljuje za korišćenje servisa ograničeno je i 
naziva se zakup servisa; kada istekne period zakupa, korisnik servisa mora da 
uputi registru zahtev za obnovu ugovora o zakupu servisa; kada ograničenje 
trajanja konekcije ne bi postojalo moglo bi se desiti da korisnici beskonačno 
dugo drže resurse veb-servisa a time i provajdera servisa. 

4.3.2 SOA - arhitektura 

SOA se bazira na višeslojnom ( n-tier ) logičkom modelu. Slojevi SOA logičke 
arhitekture prikazani su na slici 27. [124]: 

Sloj operativnog radnog sistema: Ovaj sloj sadrži resurse sistema: postojeće aplikacije 
uključujući CRM ( customer relationship management ) i ERP ( enterprise resource 
planning), starije objektno orijentisane sisteme, aplikacije poslovne inteligencije i baze 
podataka. Preko servisno orijentisanih integracionih tehnika ovi postojeći sistemi se 
mogu integrisati u SOA. 

Sloj komponenata servisa: U ovom sloju se nalaze komponente odgovome za 
realizaciju funkcionalnosti i podržavanje odgovarajućeg kvaliteta ponuđenih servisa 
(upravljanje, dostupnost i nivelacija opterećenja kome je izložen servis). 

Sloj servisa: Ovaj sloj sadrži stvarne servise koji se mogu lako otkriti i potraživati od 
strane drugih korisnika (aplikacija) sa ciljem pružanja specifičnih poslovnih funkcija za 
korisnike. Servisi mogu biti jednostavni i složeni. 

Sloj kompozicije poslovnog procesa: Servis može biti sastavljen u jedinstvenu 
aplikaciju putem orkestracije ili koreografije usluge, što podržava specifičnu upotrebu 
slučajeva i poslovnih procesa. 

Sloj korisnika servisa: Korisnički sloj je mesto gde korisnici servisa, bez obzira da li su 
to osobe, programi, drugi veb-servisi ili pretraživači, komuniciraju sa SOA. Pmža 
korisničke interfejse za servise i složene aplikacije. Korisnicima je omogućen pristup 
preko različitih kanala (veb-stranice, klijentske aplikacije, mobilnog uređaja, tenninal 
itd.) 

Dmga pitanja koja se tiču SOA jesu integracija servisa i aplikacija unutar sistema 
podržavanjem parametara kao što su pouzdanost, odgovarajuće usmeravanje i 
koordinacija servisa, i upravljanje drugim tehničkim detaljima uključujući ugovor o 
protokolu i strane zadužene za integraciju. Zahtevi kvaliteta servisa ( Quality of Service, 
QoS), sigumost, upravljanje i praćenje servisa takođe su zahtevi o kojima treba voditi 
računa prilikom dizajna servisno orijentisanih arhitektura. 
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Slika 27. Model višeslojne logičke arhitekture SOA [124] 
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4.3.3 SOA - prednosti i nedostaci 

Jedna od ključnih prednosti primene SOA jeste interoperabilnosti i laka integracija 
različitih sistema. Jedan od vodećih problema poslovnih sistema današnjice jeste 
nepostojanje zajedničkih standarda i mnoštvo zatvorenih poslovnih aplikacija koje se ne 
mogu na jednostavan način povezivati i međusobno komunicirati i čija je 
funkcionalnost ograničena na pristup kroz strogo definisanc prilagođene korisničke 
interfejse. Jednostavna mogućnost integracije različitih komponenata sistema i 
adaptacija otvorenih standarda mogu troškove integracije svesti na minimum i znatno 
olakšati, kako poslovanje unutar sistema, tako i poslovanje između različitih sistema. 

Ponovna iskoristivost komponenata opravdava ulaganje u infonnacione resurse ovog 
tipa jer postoji potencijal njihovog budućeg korišćenja bez potrebe za nabavkom ili 
izgradnjom novih komponenata slične ili iste funkcionalnosti. Proširivost sistema 
omogućava laku nadogradnju sistema prema novim poslovnim zahtevima i potrebama, 
bez potrebe za opsežnim reinžinjeringom sistema. Npr. tzv. WS-proširenja 
omogućavaju nadogradnju postojećeg sistema SOA zasnovanog na veb-servisima 
mehanizmima sigumosti, pouzdanosti i sl. Oslonac SOA na tehnologiju XML-a 
omogućava lakši prelazak na XML reprezentaciju poslovnih podataka i lakšu 
konsolidaciju poslovnih informacija. XML dokumenti i XML šeme omogućavaju lako 
upravljanje, smeštanje i analizu poslovnih podataka. Troškovi povezani uz 
skalabilnošću informacione infrastrukture znatno su smanjeni, pošto se ulaže u 
jedinstvenu komunikacionu tehnologiju zasnovanu na otvorenim standardima. 

Uprkos navedenim prednostima, adaptacija na principe SOA može dovesti i do 
negativnih posledica, pogotovo ako se ista uvodi bez potrebnih predznanja i procena 
svih mogućih uticaja na postojeći poslovni sistem. Česta greška kod prilagođavanja 
sistema SOA konceptu, je pristup od-dna-prema-gore ( bottom-up approach), gde se 
implementacija arhitekture SOA svodi samo na proširenje postojećih aplikacija pomoću 
interfejsa veb-servisa dok se tipovi podataka koje one koriste direktno preslikavaju u 
XML šeme i navode kao parametri metoda servisa. Rezultat ovoga može biti skup 
servisa, koji uprkos korišćenju istih standarda nemaju dosledno definisane tipove 
podataka za razmenu, pa je time integracija otežana, stepen interoperabilnosti manji, a 
ulaganje u SOA neopravdano. Uvođenje SOA sa sobom donosi i određeni uticaj na 
perfonnanse sistema. Mapiranje podataka na XML prikaz, provere ispravnosti i obrada 
XML dokumenata često mogu negativno uticati na performanse celog sistema. Zbog 
toga arhitekturu SOA treba uvoditi postepeno, uočavajući potencijalne probleme i uska 
grla koja najviše utiču na pogoršanje performansi i lošu efikasnost sistema. Veb-servisi 
predstavljaju jedno od najraširenijih tehnologija za implementaciju SOA arhitekture, ali 
oni izvorno ne sadrže sigurnosne mehanizme. Otvaranje poslovnih aplikacija kroz 
interfejse veb-servisa može nenamemo stvoriti sigumosne mpe unutar sistema i 
kompromitovati osetljive informacije unutar poslovnog sistema i omogućiti neovlašćeni 
pristup infonnacijskim resursima. Zbog toga je ključno unapred oceniti sigurnosne 
zahteve nad sistemom i pronaći adekvatno rešenje njihove implementacije. 

4.3.4 SOA - tehnologije za realizaciju 

SOA i tehnologija veb-servisa često se međusobno izjednačavaju iako se zapravo radi o 
dva različita koncepta. Principi SOA su stariji od veb-servisa - npr. tehnologija CORBA 
(Common Object Request Broker Architecture) i Microsoft- ov DCOM (Distributed 
Component Object Model) odgovaraju osnovnim principima SOA jer nude mogućnost 
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izgradnje slabo povezanih servisa-fimcionalnosti sa standardizovanim interfejsima. Ove 
tehnologije se doduše ne spominju često kao tehnologije za realizaciju arhitekture SOA 
iz nekoliko razloga - DCOM nije bio platfonnski neutralan, već usko povezan uz 
proizvode kompanije Microsoft, dok je CORBA bila implementirana od većeg broja 
proizvođača softvera, ali konačna rešenja nisu bila međusobno kompatibilna. 

XML, SOAP i konačno tehnologija veb-servisa prve su tehnologije koje su gotovo bez 
izuzetka podržavale sve zahteve SOA. Ono što je ključno jeste činjenica da su početkom 
21. veka veliki proizvođači softvera prihvatili tu tehnologiju i počeli razvijati rešenja 
koja su - za razliku od tehnologije CORBA - bila kompatibilna pa su se mogla lako 
integrisati u jedinstveni informacioni sistem. Može se reći da su od 2002. do 2007. 
godine pojam SOA i pojam veb-servisa u gotovo svim aspektima bili gotovo 
jednoznačni. 

Krajem prve dekade 21. veka neki stručnjaci smatraju da pojam SOA polako nadrasta 
tehnologiju veb-servisa [124]. Zahtevi modernog poslovnog infonnatičkog tržišta rastu 
u opsegu i kompleksnosti što tehnologija ne može da prati. Primer toga su proširenja 
tehnologije veb-servisa, tzv. WS-Extensions, o kojima će kasnije biti reči. Ova 
proširenja za sada još nisu deo standarda veb-servisa već su predmet stalne rasprave i 
međusobnog preuzimanja nadležnosti od strane velikih proizvođača softvera, koji su 
čak u nekoliko navrata izdali paralelne specifikacije iste predviđene funkcionalnosti. 
Zbog toga se predviđa sve jače razdvajanje pojma SOA i pojma veb-servisa tj. prelazak 
pojma SOA na viši nivo apstrakcije dok veb-servisi postaju samo jedan u nizu gradivnih 
blokova SOA. Takođe, očekuje se šira primena veb-usluga pošto one kao tehnologija ne 
moraju nužno funkcionisati samo kao deo SOA. Usprkos tome, trenutno veb-usluge i 
dalje važe kao glavna i ključna tehnologija za izgradnju SOA. 

4.3.5 Veb-servis kao tehnološka infrastruktura SOA 

Veb-servisi su tehnološka infrastruktura, tj. skup međusobno povezanih tehnologija čija 
sinteza omogućava traženu funkcionalnost. World Wide Web konzorcijum definiše veb- 
servise kao programske interfejse za komunikaciju između aplikacija preko veb-a. Ova 
definicija naglašava da veb-servis omogućava komunikaciju računara sa računarom. U 
istom smislu druga definicija navodi da je veb-servis usluga koja se izvršava na 
Intemetu korišćenjem veb-protokola i da ne uključuje akciju čoveka [124]. Veb-servisi 
su distribuirane funkcionalne softverske komponente koje su sposobne za međusobnu 
komunikaciju i komunikaciju sa aplikacijama preko standardnih Internet protokola, pa 
su kao takve ponuđene za korišćenje u razvoju dmgih aplikacija. Dmgim rečima, veb- 
servisi su zamišljeni kao gradivni blokovi za kreiranje otvorenih, interoperabilnih, 
distribuiranih aplikacija. Veb-servisi su modularne, samoopisujuće aplikacije koje se 
mogu objaviti, locirati i pozvati sa bilo koje tačke veb-a ili lokalne mreže. Veb-servisi 
se ponašaju nezavisno jedan o dmgog, a prema svojim korisnicima se predstavljaju kao 
cme kutije. Njihova interna implementacija je nevidljiva za korisnika. 

4.3.5.1 Simple Object Access Protocol (SOAP) 

SOAP ( Simple Object Access Protocol) je protokol nastao zajedničkim radom IBM-a i 
Microsofta. Njegov dalji razvoj na sebe je preuzeo W3C. To je protokol za slanje 
pomka i poziva udaljenih procedura (RPC, ili Remote Procedure Calls), baziran na 
XML-u. SOAP ne definiše novi aplikacioni protokol, već koristi postojeće internet 
protokole poput HTTP-a i SMTP-a. SOAP povezuje koncept veb-servisa sa postojećom 
intemetskom infrastmkturom. RPC ili poziv udaljene procedure je vrsta protokola koji 
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programu koji se obavlja na klijentskom računaru omogućava izvršenje programa na 
serveru. 

SOAP delinišc kako aplikacije mogu da komuniciraju, i to na sledeći način: 

• komunikacija je orijentisana na razmenu poruka, što znači da aplikacije mogu da 
komuniciraju jedna sa drugom, razmenom tekstualnih poruka; format ovih 
poruka je specificiran u SOAP-u; 

• SOAP poruka ima jednostavnu strukturu koja se sastoji od XML parent 
elementa sa dva child elementa: zaglavlja i tela; 

• SOAP poruke primaocu daju informaciju o tome kako poruke treba da se obrade 
i ko treba da ih obradi; 

• RPC-i, tj. izvršenje programa ili delova programa, procedura, ostvaruje se sa 
SOAP protokolom. 

Na današnjem Intemetu veliki broj aplikacija komunicira koristeći TCP (Transmission 
Control Protocol ) i IP (Internet Protocol) protokole. Problem na koji nailaze je u tome 
što većina aplikacija ima posebne aplikacione protokole kojima mogu da komuniciraju 
samo s ograničenim brojem drugih aplikacija. HTTP protokol je aplikacioni protokol 
koji se u mrežnoj arhitekturi nalazi iznad TCP protokola i služi za komunikaciju između 
veb-pretraživača i provajdera. Iako je HTTP vrlo uspešan protokol, ograničen je na 
samo nekoliko jednostavnih operacija - GET, POST i PUT. Rezultat toga je da 
međusobno povezane aplikacije koriste tu povezanost samo za Internet pretraživanje, a 
ne da bi bez ograničenja razmenjivale podatke. SOAP rešava taj problem definisanjem 
standardnog načina komunikacije između aplikacija. SOAP omogućava komunikaciju 
među aplikacijama iznad bilo kog protokola uključujući i TCP. Arhitektura SOAP 
protokola prikazana je na slici 28. 


SOAP omotnica 


SOAP zaglavlje 


Delovi zaglavlja 


Delovi zaglavlja 


SOAP telo 


Delovi tela 


Delovi tela 


Slika 28. Arhitektura SOAP poruke [124] 
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SOAP je aplikacioni protokol i kao takav može da radi iznad bilo kog prenosnog 
protokola. Današnji Internet prepun je zaštitnih mehanizama koji dozvoljavaju jedino 
komunikaciju preko HTTP protokola. I pored toga, a u cilju pouzdanog povezivanja 
aplikacija, SOAP mora da omogući prenos podataka. To se postiže postavljanjem 
SOAP-a, u mrežnoj arhitekturi, iznad HTTP-a. Postavljanje SOAP-a iznad HTTP-a 
znači da su SOAP poruke deo HTTP poruka i kao takve mogu da se prenose preko svih 
mreža koje propuštaju HTTP protokol. HTTP je dobar izbor i zbog toga što je nezavisan 
od platforme i uređaja koji ga koriste. Kako bi postigao platformsku nezavisnost SOAP 
za predstavljanje podataka koristi XML. Kao i HTTP, XML je platformski nezavisan. 
Zahvaljujući tome SOAP omogućava komunikaciju između aplikacija bez obzira na 
platfonnu na kojoj se izvode i mrežu na kojoj su postavljeni. 

Osnovna prednost SOAP-a je u tome što je jednostavan. SOAP nije zamišljen da reši 
sve probleme distribuiranih sistema, već da dcfinišc onaj minimum koji je potreban da 
bi aplikacije mogle međusobno da komuniciraju. SOAP se zasniva na prenosu SOAP 
poruka od pošiljaoca (sender) do primaoca ( recipient ). Da bi se shvatio SOAP najbolje 
je na SOAP poruke gledati kao na poruke koje se razmenjuju između klijenta i mrežne 
usluge. Arhitektura SOAP poruke (slika 28.) sastoji se od omotača ( envelope ) koji može 
da ima zaglavlje ( header ) i mora da ima telo ( bodv ). Unutar tela SOAP poruke nalaze se 
podaci (teret) koje treba preneti od pošiljaoca do primaoca. 

4.3.5.2 Web Services Description Language (WSDL) 

Kao što se XML šema koristi za opisivanje tipova podataka veb-servisa, tako postoji i 
potreba za jezikom koji bi opisivao čitav interfejs veb-servisa. WSDL ( Web Service 
Description Language) opisuje interfejs veb-servisa, protokole koje podržava veb-servis 
i lokaciju na kojoj je servis smešten. 

Apstraktne definicije 



Slika 29. WSDL opis veb-servisa [124] 

Aplikacija koja želi da koristi neki veb-servis koristi WSDL datoteku kako bi saznala 
lokaciju tog servisa, dostupne pozive funkcije i načina pristupa (za svaki poziv funkcije 
WSDL opisuje njegov oblik). Korisnik koji poziva uslugu aplikacije prvo od provajdera 
dobija WSDL datoteku, a onda koristi informacije iz te datoteke kako bi oblikovao 
SOAP zahtev. Moguće je odrediti sintaksu za poziv funkcije bez WSDL-a, samo iz 
dostupne dokumentacije, ali pritom je u komunikaciju uključen čovek. Sa WSDL-om se 
taj postupak rnože automatizovati. WSDL opis veb-servisa rnože se podeliti u dva 
osnovna dela, kako je prikazano na slici 29. 
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4.3.5.3 Universal Description, Discovery and Integration (UUDI) 

Prilikom kreiranja i stavljanja u upotrebu veb-servisa, potrebno je imati na umu 
činjenicu da potencijalni korisnici tih servisa najpre moraju saznati gde su oni dostupni. 
WSDL dokumenti jasno određuju pristupne tačke za pojedini servis i kako se njime 
koristiti, ali problem je u tome što korisnici treba da pronađu mesto gde se WSDL 
dokumenti nalaze. Zbog toga je potrebno stvoriti mehanizme koji će na brz i 
jednostavan način omogućiti otkrivanje podataka potrebnih za pristup veb-servisima. To 
su u stvari registri koje provajderi servisa pune informacijama o svojim servisima, a 
korisnici ih pretražuju ne bi li našli ono što ih zanima. 

Provajder servisa, nakon što je kreirao određeni servis, čuva podatke o njemu na mesto 
koje je poznato potencijalnom korisniku (javni UDDI registar). Korisnik zatim 
pretražujući podatke nalazi infonnaciju potrebnu za pristupanje servisu i njihova 
saradnja može da počne. Najvažniji mehanizam za otkrivanje veb-servisa danas je 
UDDI standard ( Universal Description, Discoverv and Integration ). To je standard koji 
je uveliko doprineo opštem prihvatanju i upotrebi veb-servisa na Intemetu. 
Implementacija UDDI specifikacije je UDDI poslovni registar (UDDI Business 
Registrv). Namenjen je provajderima koji žele da objave svoje servise i korisnicima koji 
određene servisa traže. Taj telefonski imenik veb-servisa koristi standardnu industrijsku 
klasifikaciju za kategorizaciju poslovnih i dmgih tipova servisa. Postoje: 

• bele stranice, koje opisuju provajdera servisa (ime, adresu, kontakt itd); 

• žute stranice sadrže industrijske kategorije; 

• zelene stranice opisuju interfejs servisa (WSDL). 

Korisnici mogu pretraživati UDDI registar po industrijskim i proizvodnim kategorijama, 
i po geografskoj lokaciji. Kao rezultat pretraživanja dobija se XML datoteka koja sadrži 
infonnacije (linkovi, tehnički podaci itd) na temelju kojih se mogu naći servisi koji 
odgovaraju zahtevima. 

4.4 Veb-servisi 

Definicija veb servisa od strane World Wide Web konzorcijuma (W3C) jeste: „Veb- 
servis je sistem dizajniran da podrži interakciju raznorodnih sistema preko mreže“. 
Osnovni cilj, sa kojim je počelo projektovanje i primena veb-servisa jeste omogućiti 
povezivanje raznovrsnih distribuiranih softverskih komponenata, bez obzira na kojoj su 
platformi realizovane, koji je programski jezik pri tom korišćen, kao i platforma na 
kojoj se izvršavaju. Sa ovim ciljem se kreće u realizaciju veb-servisa a neka vizija 
sistema koji se pri tome ima na uvid je da se veliki broj nezavisnih komponenti 
dostupnih preko Intemeta upotrebi na bilo kojoj platformi i u svim razvojnim 
programskim jezicima. Prema ovome veb-servise treba shvatiti kao skup aplikacija 
objavljenih na vebu koje se mogu pozvati sa bilo koje tačke na Intemetu. veb-servisu je 
moguće pristupiti preko računarske mreže, kao što je Intemet, što omogućava da se 
servis nalazi na udaljenim računarskim sistemima. Prema W3C fondaciji veb-servis 
obuhvata više raznorodnih sistema, ali zajedničko za sve definicije je da se termin veb- 
servis odnosi na klijent-server arhitektum, gdje klijent i server komuniciraju preko 
HTTP protokola, koji je široko rasprostranjen kao Intemet protokol. Aplikacije 
zasnovane na ovim standardima mogu se razvijati bilo gde, u bilo koje vreme i na bilo 
kojim sistemima koristeći prednosti unapred izgrađenih komponenata, ubrzavajući 
izradu aplikacija i smanjujući cenu razvoja novih sistema. Veb-servis predstavlja bilo 
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koji servis koji je dostupan preko Intemet mreže, koristi standardizovani XML sistem za 
razmenu pomka i nije vezan ni za jedan operativni sistem ili programski jezik. 

4.4.1 Arhitektura veb-servisa 

Pre pojave veb-servisa pojavljivao se problem pri pokušaju integracije različitih 
aplikacija, koji je nastajao uglavnom zbog različitih programskih jezika i tehnologija 
koje su korišćene pri kreiranju tih aplikacija. Verovatnoća da su dva poslovna sistema 
razvijena korišćenjem istog programskog jezika vrlo je mala, a često je potrebno 
zajednički koristiti njihove komponente integrišući ih na taj način u jedno zajedničko 
poslovno rešenje. Da bi se veb-servisi primenili za integraciju različitih aplikacija, one 
treba da budu prilagođene za upotrebu putem Intemeta. 



Slika 30. Povezivanje različitih platfonni i tehnologija pomoću SOA i veb-servisa [124] 

Korišćenjem standardnih protokola za razmenu podataka putem Intemeta 
(komunikaciona interoperabilnost), koji su nezavisni od računarske platforme, veb- 
servisi u svom radu prihvataju i realizuju zahteve klijenata. Komunikacija klijenata i 
servisa odvija se razmenom XML dokumenata pa se iz tog razloga veb-servisi nazivaju 
XML veb-servisima. Primena XML standarda omogućava da razmena podataka između 
klijenata i veb-servisa ne zavisi od tehnologije koja je nosilac izvora podataka, a ni od 
računarske platforme koja je u pozadini (slika 30.). Pri tome klijenti koji koriste veb- 
servise mogu biti različiti: mobilni telefoni, PDA uređaji, veb-pretraživači, dmge 
aplikacije, poslovni sistemi i drugi veb-servisi. 

Vizija upotrebe veb-servisa predviđa njihovo registrovanje u privatnim i javnim 
poslovnim registrima, tako da kreatori servisa opisuju komponente servisa, dehnišu 
njihove interfejse, poslovnu logiku i uslove korišćenja. Mogući scenario korišćenja veb- 
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servisa može se prikazati sledećim koracima: 

• kreator veb-servisa kreira osnovne komponente servisa, sklapa ih međusobno i 
priprema za korišćenje, koristeći programski jezik i platformu po vlastitom 
izboru; 

• kreator veb-servisa clcfinišc i opisuje veb-servis korišćenjem WSDL-a (Web 
Service Description Language), omogućavajući dostupnost servisa drugim 
korisnicima; 

• kreator veb-servisa registruje servis u UDDI ( Universal Description, Discoverv 
and Integration) registru; ti registri omogućavaju razvojnim timovima 
objavljivanje njihovih servisa kao i pretraživanje i korišćenje drugih objavljenih 
servisa; 

• potencijalni korisnik pronalazi veb-servis pretraživanjem UDDI registra; 

• korisnička aplikacija, veb-pretraživač ili uređaj za mobilnu komunikaciju 
povezuje se na odabrani veb-servis korišćenjem SOAP-a (Sitnple Object Acces 
Protocol), HTTP ili WAP protokola koji nude mogućnost korišćenja XML 
formata za slanje parametara komponentama servisa i prihvatanja rezultata 
obrade. 

Veb-servisi svoju funkcionalnost, interoperabilnost i mogućnost izvršenja tri osnovne 
operacije (slika 31.): objavljivanje, traženje i korišćenje, postižu pomoću standardnih 
protokola, koji su prihvaćeni među vodećim informatičkim firmama (Microsoft, Sun, 
IBM itd). 



Slika 31. Arhitektura veb-servisa [124] 

Na slici 32. prikazan je stek protokola veb-servisa. Sa desne strane prikazani su zahtevi 
koji bi trebali da budu zadovoljeni kroz svaki sloj modela. Sa leve strane navedeni su 
protokoli kojima se ostvaruju određene funkcionalnosti. Osnovni sloj steka protokola 
veb-servisa je mreža. Veb-servisi moraju da budu klijentima dostupni preko mreže. 
Veb-servisi koji su javno dostupni na Internetu koriste uobičajene mrežne protokole. 
Zbog svoje dostupnosti HTTP protokol je de facto standardni mrežni protokol za veb- 
servise dostupne na Intemetu. Dozvoljeno je da komunikacija s veb-servisom bude 
ostvarena ne samo HTTP-om, već i FTP-om (File Transfer Protocol), elektronskom 
poštom, a moguća je i upotreba infrastmktura poput CORBA-e, ali se prepomčuje njeno 
korišćenje samo u intranet mrežama. Sledeći sloj, razmena XML pomka, predstavlja 
XML kao osnovu za izradu protokola za razmenu pomka. SOAP (Simple Object Access 
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Protocol) je protokol za razmenu podataka kodiranih XML-om između klijenta i 
provajdera. Sloj opis servisa je sloj koji se sastoji samo od dokumenata. WSDL ( Web 
Services Description Language ) je standard za opis veb-servisa i takođe se bazira na 
XML-u. UDDI ( Universal Description, Discovery and Integration ) je specifikacija 
zasnovana na XML-u. Osnovna namena UDDI-a jeste da pruži način za objavljivanje i 
pronalaženje veb-servisa. Komunikacija klijenta i provajdera s UDDI-em odvija se 
pomoću SOAP protokola. Na samom vrhu nalazi se WSFL ( Web Services FIow 
Language). WSFL je XML jezik namenjen opisivanju načina povezivanja veb-servisa. 
U WSFL-u su raščlanjena dva načina povezivanja veb-servisa: 

• Ussage pattern - opisuje na koji način postići određeni poslovni cilj (opisuje 
kojim redom je potrebno koristiti veb-servise da bi se postigao cilj); 

• Overall partner interactions - opisuje međusobni uticaj veb-servisa jednih na 
druge (ne prikazuje niz poziva kojim se postiže određeni cilj, već prikazuje sva 
moguća međudejstva veb-servisa). 

Da bi se izradili i uspešno koristili veb-servisi, nisu potrebni svi slojevi modela. Slojevi 
objavljivanja, otkrivanja i protoka veb-servisa nisu neophodni za njegovu izradu. 
Objavljivanje, otkrivanje i protok veb-servisa nije neophodan ukoliko osoba koja gradi 
klijenta poseduje infonuacije o veb-servisu. 
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Slika 32. Stek protokola veb servisa [124] 

Za implementaciju veb-servisa razvijeno je nekoliko tehnologija. Dve najpoznatije 
tehnologije su Microsoft-ov a .NET platforma, a druga tehnologija je vezana uz razvoj 
servisa i klijenata u Java programskom jeziku. Razvoj veb servisa u Javi zasniva se na 
korišćenju Apache SOAP Toolkit -а (biblioteka funkcija koje omogućavaju SOAP 
komunikaciju između klijenata i veb servisa). IBM je izdao programski paket weh 
services Too/kit, koji, uz Apache SOAP, sadrži biblioteku funkcija koje podržavaju 
pristup UDDI registru i rad s WSDL dokumentima. Uz biblioteke funkcija, Web 
services Toolkit sadrži nekoliko programa namenjenih automatskom generisanju 
programskog koda i dokumenata koji olakšavaju izradu veb-servisa. 

4.4.2 Sigurnost informacionih sistema zasnovanih na SOA i veb-servisima 

Sigumost aplikacija jedan je od njihovih najvažnijih aspekata, kako pri njihovom 
razvoju, tako i u toku njihove eksploatacije. Kada se govori o sigumosti u oblasti 
informacionih tehnologija, mogu se posmatrati tri razdvojene, ali gotovo podjednako 
važne komponente: hardver sa komunikacionom infrastmkturom, softver i podaci. 
Svaka komponenta ima svoju vrednost u okvim sistema i zahteva posebne tehnike 
zaštite. Osjetljivost sistema, pretnje, napadi i kontrola mogu se jednim tenninom nazvati 
sigurnosnim aspektima. Osetljivost predstavlja sigumosnu slabost sistema koja postoji u 
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proceduri, dizajnu ili samoj implementaciji, a koja može biti iskorišćena za zloupotrebu 
sistema. Primera radi, neki sistem može da bude osetljiv po pitanju neovlašćene 
manipulacije podacima zato što nema implementiran mehanizam utvrđivanja identiteta 
korisnika pre omogućavanja pristupa podacima. 

Pretnja predstavlja skup okolnosti koje potencijalno mogu da naprave štetu sistemu. Za 
lice ili sistem koji pokušava da iskoristi ili iskorištava osetljivost sistema kaže se da vrši 
napad na sistem. Kontrola je zaštitna mera, odnosno akcija, procedura, uređaj ili tehnika 
koja uklanja ili u značajnoj meri umanjuje osetljivost sistema, čime onemogućava ili u 
značajnoj meri otežava vršenje napada na sistem, odnosno sistem štiti od pretnji. 
Generalno, sigumosne pretnje mogu se podeliti u četiri grupe: 

• presretanje - situacija u kojoj neovlašćena strana dobija pristup nekom resursu 
sistema ili podacima koji se prenose; 

• prekid (ometanje) - situacija u kojoj sistem, zbog aktivnosti napadača, postaje 
nedostupan ili je njegovo korišćenje jako otežano za legitimne korisnike 
sistema; 

• modifikacija - situacija u kojoj neovlašćena strana ne samo da ima pristup 
nekom resursu sistema, već nad tim resursom vrši i promene; 

• fabrikovanje - situacija u kojoj neovlašćena strana izvrši fabrikaciju, odnosno 
krivotvorenje nekog resursa sistema koji dalje legitimnim korisnicima 
predstavlja kao legitiman resurs. 

Primena SOA u projektovanju i realizaciji distribuiranih sistema donela je novine i u 
pogledu sigumosti. Ne samo da se javila potreba za razvojem novih sigumosnih 
koncepata i tehnika, već se ispostavilo da su mnoge do sada često korištene sigumosne 
prakse u slučaju SOA nedovoljne, pa čak i kontraproduktivne. Za razliku od ranijih 
distribuiranih sistema, SOA podrazumeva slabu spregu. Isto tako, klijenti veb-servisa i 
veb-servisi mogu da budu implementirani u različitim jezicima, i distribuirani na 
različitim platfonnama. Zbog toga, prethodno veoma populami centralizovani pristup 
sigurnosti više nije moguć. SOA implementacija u vidu veb-servisa obično 
podrazumeva da se komunikacija između klijenata i servisa vrši preko HTTP/HTTPS 
(.Hypertext Transfer Protocol i Hypertext Transfer Protocol Secure ) transportnog 
protokola, što isto tako može predstavljati dodatni sigumosni problem [124]. 

4.4.2.1 Elementi i dimenzije sigurnosti veb-servisa 

Pošto se veb-servisi zasnivaju na istim osnovnim HTTP i veb-arhitekturama kao i 
uobičajene veb-aplikacije, podložni su sličnim pretnjama i ranjivostima. Sigumost veb- 
servisa bazira se na nekoliko važnih koncepata koji uključuju [171]: 

• identifikaciju i autentifikaciju; identifikacija je provera identiteta korisnika, 
procesa ili uređaja; autentifikacija je skup metoda za provem istinitosti 
saopštenog identiteta; identifikacija i autorizacija obično idu zajedno, radi 
pouzdanijeg utvrđivanja identiteta kao preduslov za omogućavanje pristupa 
resursima informacionog sistema; 

• autorizacija; pristupna prava za korišćenje resursa informacionog sistema za 
korisnike, procese ili uređaje čiji je identitet potvrđen na zadovoljavajući način; 

• integritet; potrebno je obezbediti mehanizme kojima se može verifikovati da nije 
došlo do neovlašćene-zlonamerne ili slučajne izmene podataka u toku prenosa, 
obrade ili na mestu gde su sačuvani; 
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• neporecivost; neporeciv dokaz slanja i prijema podataka i identiteta pošiljaoca; 

• tajnost; podatke mogu videti samo legitimni korisnici; podaci moraju biti 
nečitljivi za neautorizovane korisnike čak i ako nađu načina da zaobiđu 
mehanizme za kontrolu pristupa; tajnost se najčešće postiže kriptovanjem 
podataka; 

• privatnost; privatnost je ljudsko pravo; opisuje pravo osobe na ograničenje 
pristupu i korišćenju njenih ličnih podataka; lični podaci su potrebni 
pojedincima ili organizacijama za pružanje usluga, ali oni se ne smeju 
redistribuirati trećim stranama bez znanja i saglasnosti osobe na koju se odnose; 
privatnost se može osigurati kombinacijom tehničkih i zakonskih sredstava. 

Defmisane su sledeće dimenzije sigumosti kod veb-servisa [171]: 

• siguma razmena poruka ( secure messaging ); 

• zaštita resursa ( resource protection ); 

• pregovaranje o ugovorima ( negotiation of contracts ); 

• upravlj anj e poverenj em (trust management ); 

• sigumosna svojstva softvera veb-servisa (securitv properties). 

Ove dimenzije obuhvataju prethodno navedene elemente sigurnosti. Svaka dimenzija je 
od suštinskog značaja za razvoj sigurnih aplikacija korišćenjem veb-servisa. 

4.4.2.2 Sigurna razmena poruka i zaštita resursa 

Komunikacija sa javnim veb-servisima obavlja se pomoću pomka preko Intemeta, koji 
je poznat po svojoj nesigurnosti. Pri dizajnu SOAP protokola koji predstavlja 
komunikacioni mehanizam za povezivanje veb-servisa, nije se vodilo računa o 
sigurnosti. Otvorena priroda Intemeta omogućava da SOAP paketi mogu biti lako 
preuzeti, pročitani ili promenjeni od strane neovlašćenih osoba. Na raspolaganju je 
nekoliko opcija kojima se može obezbediti siguma razmena pomka sa veb-servisima 
[124], [171]: 

• HTTP preko SSL/TSL (HTTPS); pošto se za prenos SOAP poruka koristi HTTP 
protokol, veoma je jednostavno sa HTTP preći na HTTPS. 

• XML Encrvption i XML Signature (XML kriptovanje i XML digitalni potpis). 
XML sigurnosni standardi razvijeni od strane W3C dopuštaju da XML sadržaj 
bude elektronski potpisan i kriptovan; pošto su sve SOAP pomke pisane u XML 
formatu, kreatori veb-servisa mogu elektronski potpisati ili kriptovati bilo koji 
deo SOAP pomke korišćenjem ovih standarda; problem je što ne postoji 
standardni mehanizam za infonnisanje primaoca kako su ovi standardi 
primenjeni na poslatu pomku; 

• WS -Securitv. W S-Securitv jc razvijen kao proširenje SOAP standarda, tako što 
obezbeđuje mehanizam za korišćenje XML Encription i XML Signature pri 
razmeni SOAP pomka; WS -Securitv definiše element SOAP zaglavlja u koje se 
mogu uključiti sigumosne informacije u XML dokument. 

Kada su resursi javno dostupni, veoma je važno da budu adekvatno zaštićeni. Obično, 
veb-servisi treba da budu dostupni samo ovlašćenim korisnicima tako da se zahteva 
mehanizam za kontrolu pristupa. Da bi se izvršila kontrola pristupa, potrebno je da se 
veb-servisi međusobno identifikuju i autentifikuju. Nekoliko različitih metoda je na 
raspolaganju, uključujući autentikaciju na transportnom sloju, token autentikaciju preko 
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WS Security standarda SAML (Security Assertion Markup Language) potvrda ili drugih 
token- a i SOAP autetifikaciono zaglavlje. Autentifikacija se za veb-servise najčešće vrši 
preko prilagođenih implementacija, ali na raspolaganju je i OASIS standard XACML 
(eXtensible Access Control Markup Language) čijom primenom se može eliminisati 
vreme i troškovi potrebni za razvoj i testiranje sopstvenih rešenja za autentikaciju [171]. 
Izazovi sa kojima se suočavamo pri zaštiti resursa prevazilaze jednostavno pružanje 
mehanizma za kontrolu pristupa. Cilj napadača ne mora da bude samo pristup veb- 
servisu. Umesto toga, ciljevi napadača mogu da uključuju ometanje rada servisa, da 
deluje kao „čovek u sredini“, prisluškivanje, lažno predstavljanje, ili čak koristeći 
slabosti u implementaciji servisa u cilju kontrole platforme ili sistema u kome se servis 
nalazi [124]. 

4.4.2.3 Referentni model sigurnosnih standarda veb-servisa 

Zajednica za otvorene standarde koja je stvorila veb-servise razvila je niz sigumosnih 
standarda za veb-servise. Na slici 33. prikazan je referentni model koji povezuje 
različite standarde sa različitim funkcionalnim slojevima za tipičnu implementaciju veb- 
servisa. Ovi slojevi nisu hijerarhijski kao što su to za TCP/IP ili OSI referentni model. 


Sigurnosni mehanizmi 
WS-Trust 


XKMS 


Upravljanje identitetima 


WS-Federation 

Liberty Aliance 




SAML 





Zaštita poruka 


WS-SecureConversation 


WS-Security 


Bezbednost SOAP poruka 


Sigurna razmena poruka 


WS-ReliableMessaging 



Kontrola pristupa 


XACML 


SAML 


XML sigurnosni sloj 

XML Encryption 


XML Signature 



Transportni sigurnosni sloj 

SSL/TLS 


Mrežni sigurnosni sloj 

IPSec 



Slika 33. Sigurnosni standardi za veb servise: Referentni model [124] 

Standardi na mrežnom, transportnom i XML sigumosnom sloju koriste se za zaštitu 
pomka koje se prenose kroz komunikacionu mrežu. Sigurnosni standardi IPsec, 
SSL/TLS (Secure Sockets Layer / Transport Laver Security), XML Encription i XML 
Signature osiguravaju bezbednost SOAP pomka na različitim nivoima. SSL/TLS 
obezbeđuju siguran tunel za prolaz SOAP pomka, dok XML Encription i XML 
Signature obezbeđuju integritet, neporecivost i tajnost. 
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Iznad XML sigumosnog sloja postoje dve vrste standarda, jedni izgrađeni na osnovu 
SOAP specifikacije i drugi samostalni standardi. Standardi za sigurnost poruka WS- 
Securitv i WS -SecureConversation definišu korišćenje XML Signature i XML 
Encription u cilju zaštite SOAP pomke, dok standardi za pouzdanu razmenu pomka 
(.Reliable Messaging ) definišu protokole neophodne da osiguraju prijem pomke. 
Standardi za kontrolu pristupa ( Access Control) nisu jedinstveni za veb-servise, 
XACML može da definiše politiku pristupa za bilo koji sistem a SAML se može 
koristiti za definisanje tvrdnje u bilo kom okmženju. Standard WS-PoIicy u sloju polisa 
dizajniran je za kreiranje dokumenata vezanih za polise i definiše veb-servis polise 
neophodne za komunikaciju sa dmgim servisima. Specifikacija ne definiše način 
transportovanja ili pronalaženja polisa. Specifikacije za upravljanje bezbednošću 
definišu upravljanje sertifikatima kao što su PKI sertifikati unutar SOA. Standardi za 
upravljanje identitetom mogu da koriste standarde za kontrolu pristupa ( Access 
Control), standarde za polise ( Policv ) i SOAP standarde za pmžanje usluga za 
distribuciju i upravljanje identitetom korisnika i sertifikatima u SOA [124]. 

4.4.2.4 Sigurnosni standardi i zaštita veb-servisa 

Postoji više sigumosnih standarda, koji se nalaze u različitim fazama razvoja kod više 
različitih organizacija, kao i više raznih implementacija u sličnim fazama dovršenosti. 
Sa jedne strane, postojanje velikog broja sigumosnih specifikacija je dobro jer je 
neophodno za široko prihvatanje i korišćenje veb-servisa. Sa druge strane, veliki broj 
specifikacija vezanih za sigurnost veb-servisa dovodi do konfuzije kod odabira 
konkretnih specifikacija za korišćenje, odnosno zahteva veći broj ljudi u razvojnom 
timu. 


Dimenzija sigurnosti 

Zahtevi 

Odgovarajuće specifikacije 

Razmena poruka 

Tajnost i integritet 

WS-Security 

SSL/TLS 

Autentifikacija 

WS-Security Tokens 

SSL/TLS Х.509 sertifikati 

Resursi 

Autorizacija 

XACML 

XrML 

RBAC, ABAC 

Privatnost 

EPAL 

XACML 

Odgovornost 

nema 

Pregovaranje 

Registri 

UDDI 

ebXML 

Otkrivanje semantike 

SWSA 

OWL-S 

Poslovni ugovori 

ebXML 

Poverenje 

Uspostavljanje 

WS-Tmst 

XKMS 

Х.509 

Posredovanje (Trust Proxying) 

SAML 

WS-Trust 

Objedinjavanje 

WS-Federation 

Liberty IDFF 

Shibboleth (lozinka) 

Sigurnosna svojsta softvera 

Polise 

WS-Policy 

Sigumosne polise 

WS-SecurityPolicy 

Dostupnost 

WS-ReliableMessaging 

WS-Reliability 


Tabela 8. Specifikacije i standardi za rešavanje sigumosti SOA [124] 
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U tabeli 8. prikazano je kojim specifikacija i standardima mogu biti zadovoljeni 
sigurnosni zahtevi veb-servisa. 

Svaka sigumosna dimenzija SOA ima jedan ili više sigurnosnih zahteva. Svaki zahtev 
može biti podržan sa bilo kojim brojem standarda. Na primer SSL/TLS i WS-Security 
pmžaju podršku za: 

tajnost; 

integritet; 

autentikaciju za dimenziju sigurne razmene podataka. 

4Л.2.5 Sigurnosna arhitektura 

Slika 34. prikazuje arhitektum veb-servisa u radnom okmženju. Komponente prikazane 
arhitekture opisane su u daljem tekstu. 


Sloj veb-servisa 

UDDI registar, ebXML 
registar, WSDL 


Sloj radnog 
okvira 
veb-servisa 
.NET, J2EE 


Sloj poruke 

SOAP, WS-Security, Saml 


Prezentacioni sloj 

XML, ebXML, XML DSig, 
XML Enc, XACML, XKMS 


Sloj veb- servisa 


Sloj sesije 
HTTP, HTTPS 


Zaštitni sloj sesije 

SSL, TLS 


Slika 34. Veb-servis - sigurnosna arhitektura [124] 

Sloj veb-servisa (IVEB Service Laver) je sloj u kome su: softver veb-servisa, podaci koji 
se obrađuju od strane veb-servisa, pomke koje veb-servis koristi za komunikaciju sa 
dmgim veb-servisima. Sloj radnog okvira veb-servisa ( WEB Services Framework 
Laver) sadrži komponente koje pmžaju sigumosne funkcije koje veb-servis koristi, ali 
koje nisu deo koda samog veb-servisa. Veb-servisi takođe rnogu da komuniciraju preko 
sloja radnog okvira sa sigumosnim servisima u sloju veb-servera ( WEB Server Layer), 
koji pmža uslugu povezivanja na mrežnom nivou i prateće usluge zaštite kao što su: 
komunikacija u okvim sesije preko HTTP i HTTPS protokola, ali i zaštita sesije 
poinoću SSL/TLS. Sloj veb-servera takođe obezbeđuje veb-servisima pristup spoljnim 
sigurnosnim mehanizmima kao što su: kontrola pristupa bazama podataka, kontrola 
pristupa sistemu datoteka, ostali sigumosni servisi. 
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4.4.2.6 Zaštita veb-servisa 

Da bi se mogao zaštititi sistem zasnovan na veb-servisima, moraju se razumeti pretnje 
sa kojima se suočava takav jedan sistem. Iako postoji mnoštvo sigurnosnih standarda i 
tehnologija dostupnih za zaštitu veb-servisa, one ne moraju biti odgovarajuće ili 
potrebne za određeni sistem ili pojedini servis. Iz tog razloga neophodno je razumeti 
pretnje sa kojima se veb-servisi suočavaju tako da se za određeni sistem može utvrditi 
koje su od tih pretnji realne da bi se izvršila zaštita veb-servisa od njih. Prema WS-I, 
najčešće pretnje sakojima se veb-servisi suočavajujesu [171], [124]: 

• izmena poruke; napadač umeće, uklanja ili menja podatke u okviru poruke u 
cilju obmane primaoca; 

• gubitak tajnosti; informacije unutar poruke postale su dostupne neovlašćenom 
korisniku; 

• falsifikovane poruke; lažne poruke koje šalje napadač, a za koje primalac veruje 
da su upućene od legalnog pošiljaoca, a ne od napadača; 

• čovek u sredini; napadač se postavi između učesnika u komunikaciji koji 
razmenjuju poruke kao posrednik koga ni jedna strana nije svesna; napadač ima 
mogućnost da pregleda i menja poruke koje prosleđuju; 

• prevara identiteta (principal spoofing ); napadač konstruiše i šalje poruku sa 
takvim potvrdama da primalac veruje da poruka stiže od drugog pošiljaoca 
(varijacija falsifikovane poruke); 

• falsifikovanje potvrde o pravima (forged claims ); napadač falsifikuje potvrde o 
pravima da bi pristupio informacijama ili nekim drugim resursima za koje nije 
autorizovan; 

• reprodukcija poruke; napadač kopira ispravan zahtev i naknadno ga više puta 
šalje u sistem; primer takvog napada bi moglo biti višestruko slanje kopije 
zahteva za prenos novca u banci, što bi rezultovalo višestrukom sumom novca 
na računu napadača; 

• reprodukcija dela poruke; napadač u poruku umeće deo druge poruke u cilju 
dobijanja dozvole za pristup informacijama ili resursima za koje nije ovlašćen; 
deo druge poruke koji se umeće može biti sigurnosna potvrda iz neke druge 
poruke; 

• DoS (Denial of Service) napadi odbijanja servisa pokušavaju onemogućiti 
sistem većim brojem zahteva nego što ih sistem može obraditi; kod običnih veb- 
stranica, DoS napade je relativno lako detektovati; međutim, kod veb-servisa 
detekcija takvih napada može biti teža; posebno kada veb-servis zahteva 
relativno puno vremena za obradu; tada čak i mali broj zahteva može 
onemogućiti sistem u daljem radu, a da pri tome automatizovani sistem detekcije 
upada i ne detektuje napad. 

Veb-servis je tehnologija bazirana na XML-u, i na nju se kao takvu odnose pravila 
XML sigurnosti. Pošto se veb-servisi koriste kao distribuirane funkcionalnosti na 
Intemetu ili u lokalnoj mreži, na nju se odnose i pravila HTTP sigurnosti. Sledeći veb- 
servisi i HTTP standardi mogu pmžiti zaštitu od navedenih pretnji [171]: 

• W3C XML Encription; upotrebljava se za šifriranje pomka i nudi tajnost cele 
SOAP pomke ili njenog dela; 

• W3C XML Signature; koristi se za digitalno potpisivanje pomka, čime se 
obezbeđuje integritet pomke i autentifikacija pošiljaoca; 

• WS -Securitv Tokens; sigurnosne potvrde se uključuju u pomku da bi primalac 
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mogao da identifikuje pošiljaoca i da odredi da li je ili nije autorizovan da izvrši 
zahtevanu akciju; 

• W3C WS -Addressing Ids; omogućava pošiljaocu poruke jedinstveni 
identifikator za svaku poruku; 

• IETF SSL/TLS; zaštićeni HTTP protokol za slanje i prijem SOAP poruka; 

• SSL/TLS sa autentifikacijom klijenta; zahteva da se primalac i pošiljaoc 
autetifikuju jedan drugom pre nego što uspostave razmenu poruka korišćenjem 
zaštićenog HTTP protokola; 

• IETF HTTP autentifikacija; omogućava da se korisničko ime i lozinka šalju kao 
deo HTTP zaglavlja. 



Izmena 
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Tabela 9. Pretnje i veb-servis standardi koji pružaju zaštitu od njih [228] 

U Tabeli 9. je prikazano koji standardi pružaju zaštitu od kojih pretnji. Tabela pokazuje 
da SSL/TSL i WS -Securitv preko XML Encription i XML signature pružaju sličnu 
zaštitu [171]. 

4.4.2.7 Ugovori poverenja i upravljanje poverenjem 

Jedan od primamih ciljeva SOA jeste da olakša automatizaciju poslovnih procesa 
omogućavajući servisima da automatski otkriju jedni druge i iskoriste ponuđene 
funkcionalnosti. Da bi se olakšalo međusobno poslovanje različitih sistema, potrebno je 
da su veb-servisi u stanju da automatski između sebe stvore i sprovode ugovor 
međusobnog poslovanja i da ga se pridržavaju. 

ebXML ( electronic business eXtensib!e Markup Language ) je jezik iz porodice XML 
jezika. Definiše protokole komunikacija i sadržaj poslovnih dokumenata koji mogu da 
se razmenjuju između poslovnih aplikacija u mreži. ebXML daje odgovore na pitanja: 
kako obezbediti transportne mehanizme za poslovne dokumente; kako učiniti sadržaj 
ovih dokumenata razumljivim; kako otkriti koji se tipovi poslovnih dokumenata mogu 
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elektronski razmenjivati [124]. ebXML predstavlja katalizator u standardizaciji 
elektronskih poslovnih rečnika (semantika), infrastrukture i poslovne dokumentacije. 

ebXML doprinosi postizanju interoperabilnosti na sledeći način: 

• korišćenjem XML kao opšteg standarda; 

• pružanj em obj edinj ene semantike koj a j e svima dostupna; 

• implementacijom ebXML, sistemi mogu da automatizuju metode i tokove svojih 
elektronskih poslovnih transakcija, čime se povećava povezanost i efikasnost 
usluga i omogućuje način za smanjenje cene i uvođenje tehnoloških inovacija. 

ebXML standardi su previše složeni da bi se koristili za jednostavne veb-servise. 
Obično, WSDL interfejs ili zapis u registru o pojedinačnom veb-servisu može se 
smatrati implicitnim ugovorom između servisa, ali ne postoje standardi koji podržavaju 
izvršavanje implicitnih ugovora. Istraživanja u oblasti koreografije veb-servisa treba da 
razreše taj problem. Jedan od osnovnih principa bezbednosti je da učesnici u transakciji 
veruju jedni drugima. Veb-servisi podržavaju različite modele poverenja koji mogu da 
se koriste da bi se omogućilo veb-servisima da veruju u identitet subjekata unutar SOA. 
Specifikacija WS -Trust opisuje modele poverenja koji omogućavaju veb-servisima da 
sigumo sarađuju. Specifikacija WS -Federation obezbeđuje skupu organizacija da 
uspostavi jedan virtualni sigumosni domen, odnosno definiše mehanizam za 
obezbeđenje informacija o identitetu, atributima, autentikaciji i autorizaciji kod servisa 
koji se nalaze u različitim sigumosnim domenima. 

Upravljanje poverenjem trenutno je ograničeno na poverenje u identitet WB servisa. 
Arhitekture modela poverenja koje se koriste su: 

• Puinvise (mudri parovi) - svaki veb-servis ima sigumosne informacije o svim 
drugim ve-servisima u SOA sa kojima interaguje; problem je kada SOA sadrži 
veliki broj veb-servisa; dodavanje novog veb-servisa predstavlja problem jer se 
informacije o njemu moraju proslediti svim ostalim veb-servisima; ovaj model 
je loš kod proširenja sistema; 

• Brokered (posrednički) - veb-servisi koriste TTP ( trusted third party ), odnosno 
posrednika od poverenja, veb-servisi treba samo da verifikuju identitet 
posrednika poverenja umesto identiteta svih ostalih veb-servisa u SOA; 

• Federated (objedinjeni). veb-servisi iz različitih organizacija mogu da sarađuju; 
ovaj model se oslanja na prethodna dva (pairwise i brokered) dozvoljavajući 
organizacijama da koriste sopstvene centralne posrednike poverenja, dok se 
oslanja na painvise ili posredničko poverenje između organizacija; 

• Perimeter defense (odbrana na granici); XML gateway (prolaz) postavljen je 
između pmžaoca i korisnika veb-servisa; XML gateway se postavlja na granicu 
SOA i ima funkciju zaštite unutrašnjih veb-servisa; u tom smislu veb-servisi 
mogu biti dizajnirani bez mehanizama sopstvene zaštite; problem je ako napadač 
uspe da preskoči XML gateway, svi unutrašnji veb-servisi koji nemaju sopstveni 
sistem zaštite podložni su napadu. 

4.4.3 Međusobno povezivanje veb-servisa 

Kod servisno orijentisane arhitekture projektovanja softvera, aplikacije više nisu 
monolitne celine, nego se sastoje od niza modulamih veb-servisa koji su gradivni 
blokovi ove arhitekture. Veb-servis se može posmatrati kao jedna softverska funkcija 
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koja se po potrebi poziva od strane korisnika servisa. Sam po sebi, veb-servis ne 
predstavlja kompletno poslovno rešenje. Povezivanjem više veb-servisa odgovarajućih 
funkcionalnosti može se izgraditi efikasno, fleksibilno i sveobuhvatno poslovno rešenje 
sposobno da se prilagođava raznim promenama (tehnologije, zakona, odnosa) u 
okruženju u kome se koristi. 

Postoje dva osnovna načina međusobnog povezivanja veb servisa u jedan složeniji 
proces. To su orkestracija odnosno koreografija i prvenstveno se razlikuju po tome ko u 
datom trenutku kontroliše izvršavanje procesa (Slika 35.). 

Orkestracija podrazumeva jedan centralni proces koji preuzima kontrolu nad svim veb- 
servisima (internim i ekstemim) uključenim u poslovno rešenje i vrši koordinaciju 
njhovog rada. Kod orkestracije veb-servisi nisu ,,svesni“ da su deo većeg procesa. 
Centralni proces obezbeđuje neometano odvijanje poslovnog procesa - tok procesa. 
Orkestracija veb-servisa je pružanje otvorenog, baziranog na standardima, pristupa za 
povezivanje veb-servisa u cilju kreiranja poslovnih procesa višeg nivoa. 

Koreografija nema centralnog koordinatora, već svaki uključeni veb-servis zna da je 
učesnik većeg procesa, zna koji veb-servis treba da pozove nakon što uspešno završi sa 
radom i šta treba da uradi ako dođe do greške. Koreografija u svojoj suštini je saradnja 
veb-servisa. 

Koreografija i orkestracija nisu koncepcije koje isključuju jedna drugu. Trenutno se više 
koristi orkestracija, prvenstveno zato što je kod nje tačno poznato ko je u svakom 
trenutku odgovoran za izvršenje procesa, pa je moguće iskoristiti postojeće veb-servise 
koji i ne trebaju da znaju da su deo većeg procesa. Njihovu implementaciju ne treba 
dodatno menjati/prilagođavati, već se koriste onako kako su dizajnirani. Ujedno, u 
orkestraciji je lakše rešavati probleme ako nešto krene kako ne treba. 

Poslovni proces se definiše kao niz aktivnosti koje se moraju izvršavati nekim 
redosledom sa ciljem ostvarenja određene funkcionalnosti ili poslovnog cilja unutar 
neke organizacione strukture (organ uprave, preduzeće). Definicija procesa opisuje 
mrežu aktivnosti, njihove odnose, jedinice koje učestvuju uključujući aplikacije, 
organizacije i ljude, tok podataka između aktivnosti i podatke koji zaokružuju proces, 
kao što su uslovi potrebni za pokretanje procesa i kraj izvršavanja. 



Koreografija 





Slika 35. Koreografija i orkestracija [124] 
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Upravljanje poslovnim procesom (Business Process Management, BPM) pruža 
infrastrukturu za dizajn, primenu, izvršavanje, održavanje i praćenje poslovnih procesa. 
BPM sistemi (Business Process Management System, BPMS) pružaju potrebne alate za 
tumačenje definicija procesa, modelovanje, razvoj i upravljanje procesima dok se 
izvršavaju. BPMS raspoređuju određene stavke procesa odgovarajućim učesnicima, a 
potrebni izvori se pozivaju na mestima gde je to potrebno. 

BPM nudi strategije koje se koncentrišu na definisanje poslovnih procesa i njihovu 
integraciju unutar i između organa uprave, a ne na razvoj čvrsto povezanih 
individualnih struktura aplikacija. Integracija poslovnih procesa uključuje integraciju 
nekoliko aplikacija pomoću različitih metapodataka, platformi i procesa. Veb-servisi su 
prihvaćena tehnologija za interpretaciju poslovnih procesa. Jezik za definisanje 
poslovnih procesa koristi se za opisivanje redosleda kojim se veb-servisi pozivaju s 
ciljem izvršenja poslovne funkcije. Iako postoje različiti jezici za definisanje procesa 
koje predlažu organizacije i dobavljači, još ne postoji standardan i univerzalno 
prihvaćen jezik za opis poslovnih procesa. Svaki od tih jezika ima različite dobre i loše 
strane kad je reč o izražavanju poslovnog procesa. 

Standardi kao što su BPEL4W, WSCI i BPML dizajnirani su da pojednostave 
međusobno povezivanje veb-servisa, da smanje cenu poslovnih procesa, i da povećaju 
efikasnost i tačnost izvršenja poslovnih procesa. Bez zajedničkog skupa standarda, 
svakoj organizaciji bilo bi ostavljeno da sama izgrađuje svoj sopstveni skup 
odgovarajućih poslovnih protokola, ostavljajući jako malo fleksibilnosti za pravu 
saradnju veb-servisa. 

4.4.3.1 Web Service Coreography Interface (WSCI) 

Web Service Coreographv Interface (WSCI) je jezik zasnovan na XML-u predložen od 
strane Intalio, SunMicrosystems-a, SAP-a i BEA Systems- a. Jezik opisuje tok poruka 
razmenjenih između veb-servisa uključenih u interakciju pružajući na taj način 
globalnu, porukama usmerenu definiciju procesa. 



Slika 36. WSCI interfejs i veb-servis [124] 

To je jezik koreografije, što znači da opisuje vidljivo ponašanje veb-servisa, a da se pri 
tom ne bavi definisanjem izvršnog poslovnog procesa i osobina transakcija. WSCI 
opisuje međusobne zavisnosti između operacija veb-servisa tako da klijent može 
razumeti kako da stupi u interakciju sa odgovarajućim servisom u kontekstu 
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predmetnog procesa, i kako bi mogao pretpostaviti kakvo će biti ponašanje tog servisa u 
svakom trenutku životnog ciklusa procesa. 

WSCI opisuje detalje ponašanja veb-servisa unutar procesa čije se izvršenje može 
pokrenuti dobijanjem odgovarajuće poruke. Jedan WSCI interfejs opisuje razmenu 
poruka sa tačke gledišta veb-servisa. Slika 36. prikazuje odnos između WSCI interfejsa 
i veb-servisa. 

4.4.3.2 Business Process Ехесипоп Language for Web Service (BPEL4WS) 

Najčešći jezik za definisanje procesa je Business Process Execution Language for Web 
Service (BPEL4WS), specifikacija koju su zajedno napisali IBM, BEA, Microsoft, SAP 
i Siebel. To je jedinstveni jezik koji u sebi nosi osobine IBM-ovog Service Flow 
Languagea (WSFL) i Microsoftovog XLANG-a. BPEL4WS koristi gramatiku 
zasnovanu na XML-u sa ciljem kreiranja definicije procesa i smešten je kao sloj na vrhu 
WSDL-a kako bi opisao potrebne komponente veb servisa za definisanje razmenjenih 
poruka, izvršenih operacija i potrebnih tipova porta. 

Jezik se koristi za podršku dva odvojena scenarija korišćenja: 

• apstraktni proces koristi se za definisanje uloge poslovnog protokola i 
identifikaciju ponašanja procesa razmene poruka između različitih strana 
uključenih u protokol, skrivajući pri tom intemo ponašanje; 

• izvršni proces identifikuje stvarno ponašanje učesnika u poslovnoj interakciji 
definišući redosled izvršavanja veb-servisa između svakog poslovnog partnera; 
on definiše kako interakcija servisa između tih partnera se koordinira i uvodi 
sistematične mehanizme za rešavanje pitanja poslovnih izuzetaka i grešaka u 
procesu. 

BPEL4WS definisanje procesa sadrži niz elemenata koji opisuju kontrolu toka, 
asinhrone interakcije, korelacije, greške, kompenzacije i dmge komponente unutar 
poslovnog procesa. Definicija procesa definiše proces kad je reč o njegovoj interakciji s 
partnerima. Partner može da pmži servis procesu, da od procesa zatraži servis, ili može 
biti u dvosmemoj interakciji s procesom. Partnerski linkovi identifikuju oblik odnosa s 
partnerom definišući tipove pomke i portova koji se koriste u oba smera. 

Slika 37. identifikuje odnos između BPEL4WS procesa i njegovih partnera. 
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4.4.3.3 Business Process Managment Language (BPML) 

Business Process Management Language (BPML) je meta jezik za opisivanje poslovnih 
procesa. Spccifikacija jezika je razvijena od strane Business Process Management 
Initiative (BPMI.org), nezavisne organizacije angažovane od strane Intalio, Sterling 
Commerce, Sun, CSC, i drugih. BPML je inicijalno dizajniran da podrži izvršavanje 
poslovnih procesa u BMP sistemima. 

BPML specifikacija pruža apstraktni model i XML sintaksu za prikaz izvršnih 
poslovnih procesa i podržanih entiteta. BPML u sebi ne definiše neki određeni proces ili 
aplikaciju procesa određene oblasti, već definiše apstraktni model i gramatiku za 
izražavanje generičkih procesa. To omogućava da se BPML koristi u različite svrhe, 
između ostalog za definiciju poslovnih procesa organa uprave ili preduzeća, definiciju 
složenih veb-servisa, definiciju višestrane saradnje i dr. 

BPML specifikacija zavisi od sledećih specifikacija: XML 1.0, XML- prostora imena, 
XML šeme i XPath 1.0. Dodatno, podrška za uvoz i referenciranje definicije servisa 
datog u WSDL 1.1 deo je specifikacije BPML. 

4.5 Semantički veb 

World Wide Web (WWW) sadrži ogromne količine informacija stvorenih od različitih 
organizacija, zajednica i pojedinaca. Korisnici veba mogu vrlo lako pristupiti tim 
informacijama i ostalim povezanim resursima preko odgovarajućih URI ( Uniform 
resource identifier ) adresa. Jednostavnost upotrebe je glavni razlog populamosti veba, 
što je dovelo do toga da većina podataka nastaje i objavljuje se putem veba i na taj način 
čini dostupnim korisnicima. 

Jednostavnost upotrebe klasičnog veba ima svoju negativnu stranu, u potrazi za 
informacijama često se dešava se umesto potrebnih i željenih pronađu nevažne i 
nepovezane informacije. Time se pretraživanja korisnika svodi na dug i mukotrpan 
posao jer se ne troši vreme samo na traženje potrebnih informacija, već korisnik gubi 
vreme razdvajajući korisne informacije od nepovezanih i nevažnih. Kako bismo 
ilustrovali ovaj problem, pretpostavimo da tražimo nešto vrlo jednostavno, tipa „Petar 
Petrović“. Kao rezultat pretraživanja dobićemo mnogo informacija, počevši od 
Facebook korisnika, različitih tekstova (knjige, časopisi, vesti) u kojima se pojavljuju 
ovo ime i prezime, pa možda i informacije o nestalim osobama. 

Vrlo je česta pojava da korisnici prilikom pretraživanja, ukoliko pretraživanje ima više 
značenja, dobiju mnogo različitih informacija. Ta višeznačnost se može odnositi i na 
nacionalne jezike, a i na pojedini jezik. Ideja semantičkog veba je jednostavna, a to je 
iskoristiti znanja, principe i tehnologije koje su u osnovi običnog veba, za novi veb koji 
bi bio univerzalan medijum za razmenu podataka, informacija i znanja. Problem 
postojećeg veba je što je oblikovan tako da njegov korisnik bude čovek, a ne mašina. 
Potrebno je uvesti nov način predstavljanja podataka na vebu, koji će biti mašinski 
čitljiv i omogućiti različitim programima da izdvoje značenje iz njih, a koji će pritom 
biti dovoljno fleksibilan da pokrije različite primene i da omogući sopstveni razvoj. 

Semantički veb [124] treba da bude proširenje postojećeg koje će omogućiti preciznije 
definisanje semantike - značenja informacija i servisa na vebu, što bi računarima 
omogućilo dublju analizu podataka - sadržaja. Za bolje shvatanje pojma sematičkog 
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veba česta je analogija u kojoj se današnji veb poistovećuje s jednom knjigom 
(razumljivo ljudima), a semantički veb s bazom podataka (razumljivo računaru). 



Slika 38. Arhitektura semantičkog vebaa sa preporukama W3C za standarde. 

Sam koncept računaru razumljivih dokumenta u semantičkom vebu ne implicira bilo 
kakvu vrstu veštačke inteligencije ili obrade ljudskog jezika (natural language 
processing ). Semantički veb samo naglašava mogućnost računara da rešava dobro 
definisane probleme pomoću dobro definisanih operacija na postojećim dobro 
definisanim podacima. Ideja je omogućiti opis informacija na vebu na način pogodan za 
računarsku obradu. Kada jezik kojim je moguće opisati informacije postoji, na ljudima 
je da opišu svoju internet stranicu ili servis tim jezikom. Kada se pojavi i neka druga 
intemet stranica opisana istim tim jezikom, one će moći da ,,razumeju“ jedna dmgu i 
međusobno razmenjuju informacije. Sa stanovišta podataka veoma je važno da se 
podaci koji se razmenjuju ili prikazuju nedvosmisleno i opišu. Da bi se omogućila 
funkcionalnost semantičkog veba, potrebno je obezbediti širok spektar standarda na 
kojima se semantički veb bazira. Na slici 38. prikazana je arhitektura semantičkog veba 
koja opisuje sve neophodne standarde. 

Unicode i URI slojevi služe da omoguće korišćenje intemacionalnog skupa znakova i 
pmže način za identifikovanje objekata u semantičkom vebu. XML sloj sa prostorom 
imena i šemom definicija osiguravaju integraciju definicije semantičkog veba sa ostalim 
standardima baziranim na XML-u. Sa RDF-om i RDF Shemom (RDFS) moguće je 
napraviti izjave o objektima sa URI-ovima i definisati rečnike kojima se može baratati 
preko URI-ova. Ovo je sloj u kom se mogu dati tipovi resursima i linkovima. Ontološki 
sloj podržava evoluciju rečnika i može definisati relacije između različitih koncepata 
[183]. 

4.5.1 Ontologije 

U svom izvomom filozofskom značenju ontologija predstavlja nauku o biću, o onome 
što postoji. U računarstvu i infonnatici ontologija znači fonnalno definisani sistem od 
pojmova i/ili koncepata i relacija između tih pojmova. Tačnije, ontologija je obrazac 
podatka koji predstavlja koncepte unutar nekog domena i odnose između tih koncepata. 
Koristi se za razumevanje objekata koji se nalaze unutar tog domena. Ontologije su 
korišćene u veštačkoj inteligenciji, semantičkom vebu i softverskom inženjerstvu kao 
oblik reprezentacije znanja o svetu ili nekog njegovog dela. 
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Kod dve različite baze podataka mogu se koristiti različiti identifikatori za ono što je u 
stvari isti pojam, kao što je npr. poštanski broj. Može se desiti da određeni program želi 
da poredi ili kombinuje informacije iz dve različite baze podataka. U ovom slučaju 
javlja se određeni problem. Naime, program mora da zna da su ova dva termina 
upotrebljena tako da znače istu stvar. U idealnom slučaju, potrebno je da program 
poseduje, odnosno ima način da otkrije takva zajednička značenja na kakve god baze 
podataka naiđe. Rešenje ovog problema nudi jedna od osnovnih komponenata 
semantičkog veba, kolekcija informacija koja se naziva ontologijama. Ontologija je 
dokument ili datoteka koja formalno definišc relacije između termina. Najpoznatija i 
najtipičnija vrsta ontologije za veb sastoji se od klasifikacije i skupa pravila 
zaključivanja. 

Klasifikacija definiše klase objekata i relacije između njih. Na primer, adresa može biti 
definisana kao tip lokacije, a šifira grada može biti definisana tako da se odnosi samo na 
lokacije. Klase, potklase i relacije između entiteta veoma su važne i korisne za 
korišćenje na vebu. Može se izraziti veliki broj relacija između entiteta tako što se 
dodeljuju osobine klasama dozvoljavajući potklasama da nasleđuju takve osobine. U 
ovom primeru ako šifra grada mora biti tipa grad, a gradovi u opštem slučaju imaju veb- 
sajtove, može se diskutovati o veb-sajtu kome je pridružena šifra grada čak i ako 
nijedna baza podataka ne povezuje šifru grada direktno sa veb-sajtom. Pravila 
zaključivanja u ontologijama donose još snage. Ontologija može izraziti pravilo, ako je 
šifiri grada pridružena šifri države, a adresa koristi tu šifru grada, onda ta adresa ima njoj 
pridruženu šifru države. Program bi onda mogao lako zaključiti, na primer, da adresa 
Narodne banke Srbije, koja je u mestu Beograd, mora biti u državi Srbiji i stoga bi 
trebalo da je formatirana u skladu sa standardima Srbije. Računar ne ,,razume“ zaista 
bilo koju od ovih informacija, ali može na osnovu klasifikacija i skupa pravila da 
manipuliše ovim terminima daleko delotvornije na načine koji su korisni i koji imaju 
značenje za čoveka - korisnika. 

Ontologije mogu poboljšati funkcionisanje veba na razne načine. Na jednostavan način 
mogu se upotrebiti da poboljšaju tačnost veb-pretraživanja. Program za pretraživanje 
može tražiti samo one stranice koje referišu precizan pojam, umesto svih onih koje 
koriste dvosmislene ključne reči. Naprednije primene koristiće ontologije da povežu 
informacije na stranici sa pridruženim im strukturama znanja i pravilima zaključivanja. 
Možemo reći da ontologiju čine rečnik i određena pravila i ograničenja u upotrebi 
termina ovog rečnika. 

4.5.1.1 Definicija ontologije i istorijska pozadina 

U kontekstu računarskih i informacionih nauka, ontologija je kolekciju reprezentacionih 
primitiva sa kojima se modeluje domen znanja ili diskurs. Reprezentacioni primitivi su 
obično klase (ili kolekcije), atributi (ili svojstva) i relacije (ili međusobni odnosi između 
članova klase). Definicije reprezentacionih primitiva uključuju informacije o njihovom 
značenju i ograničenjima njihove logički konzistentne primene. U kontekstu sistema 
baza podataka, ontologija se može posmatrati kao nivo apstrakcije modela podataka, 
analogno hijerarhijskom i relacionom modelu, ali namena joj je modeliranje znanja o 
individualnim članovima, njihovim atributima i njihovim relacijama sa drugim 
individualnim članovima. Ontologije se obično specificiraju preko jezika koji 
dozvoljavaju apstrakciju različitu od strukture podataka i implementacionih strategija; u 
praksi, ontološki jezici su po opisnoj snazi bliži logici prvog reda nego jezicima koji se 
koriste za modelovanje baza podataka. Stoga, kaže se da su ontologije na 
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,,semantičkom“ nivou, dok su šeme baza podataka modeli podataka na ,,logičkom“ i 
,,lizičkom“ nivou. Zbog njihove nezavisnosti od modela podataka, koji su na nižem 
nivou, ontologije se koriste za integrisanje heterogenih baza podataka, omogućavanje 
interoperabilnosti između različitih sistema i specificiranje interfejsa nezavisnih servisa 
baziranih na znanju. U standardima semantičkog veba [224], ontologije se tretiraju kao 
eksplicitni sloj. Danas postoje standardni jezici i varijeteti komercijalnih i otvorenih 
izvomih alata za kreiranje i rad sa ontologijama. 

Termin ,,ontologija“ dolazi iz oblasti filosofije koja se bavi proučavanjem bića ili 
postojanja (egzistencije). U filosofiji, o ontologiji se može govoriti kao o teoriji prirode 
egzistencije (npr. Aristotelova ontologija uvodi primitivne kategorije, kao što su 
materija i kvalitet, koje su pretpostavka za odgovor na Sve što je). U računarskim i 
infonnacionim naukama, ontologija je tehnički termin koji označava artifakt koji je 
projektovan za određenu svrhu, koji treba da omogući modelovanje znanja o nekom 
domenu, stvamom ili nestvarnom (imaginamom). Tennin je usvojen od strane ranih 
istraživača u oblasti veštačke inteligencije (A rtificial Intelligence ), koji su prepoznali 
primenjivost radova iz matematičke logike [116] i utvrdili da AI istraživači mogu 
kreirati nove ontologije kao računarske modele koji omogućavaju određene vrste 
automatskog zaključivanja [87]. Osamdesetih godina AI istraživači koriste termin 
ontologija koji upućuje i na teoriju modelovanja realnog sveta (npr Naive Physics [87]) i 
komponentu sistema znanja. Neki istraživači, na osnovu inspiracije iz filosofskih 
ontologija, posmatraju računarsku ontologiju kao vrstu primenjene filosofije [197]. U 
ranim devedesetim napori da se kreiraju interoperabilni standardi identifikovani su kao 
tehnološki stek koji poziva ontološki sloj kao standardnu komponentu sistema znanja 
[155]. Često citirane veb-strane i radovi [80] asocirani su sa tim naporima vezanim za 
kreiranje definicije ontologije kao tehničkog termina u računarskim naukama. Ovaj rad 
definiše ontologiju kao „eksplicitnu specifikaciju konceptualizacije“, odnosno, kao 
„objekte, koncepte, i dmge entitete za koje se pretpostavlja da egzistiraju u nekoj oblasti 
od interesa i relacije koje se uspostavljaju između njih“. Dok termini specifikacija i 
konceptualizacija mogu biti debatovani, dotle su osnovne tačke ove definicije ontologije 
sledeće: 

• ontologija definiše (specificira) koncepte, relacije i druge činioce koji su 
relevantni za modelovanje domena; 

• specifikacija uzima oblik definicija reprezentacionog rečnika (klase, relacije itd), 
koje obezbeđuju značenje rečnik i formalna ograničenja na njihovom 
koherentnom korišćenju. 

Jedini prigovor ovoj definiciji je da je preširoka, ali omogućava širok spektar 
specifikacija, počev od prostih rečnika ( glossarv ) do logičkih teorija formalizovanih 
preko predikatskog računa [195]. Ali ovo važi za modele podataka određene složenosti, 
na primer, pojedinačna tabela baze podataka i njene kolone je ipak instanca relacionog 
modela podataka. Pragmatičnije gledano, može se reći da je ontologija i alat i proizvod 
inženjeringa i definisana svojom namenom. Iz te perspektive, ono što je bitno u 
korišćenju ontologije jeste da obezbedi reprezentacionu mašineriju kojom se 
instanciraju modeli domena u bazi znanja, da omogući upite kao servise zasnovane na 
bazi znanja i predstavi rezultate rade takvih servisa. Na primer, API servis za 
pretraživanje može ponuditi ne više do rečnika tekstualnih termina kojim je formulisan 
upit, i može raditi kao ontologija. S druge strane, današnji W3C standardi semantičkog 
veba sugerišu specifičan formalizam za kodiranje ontologija (OWL) u nekoliko 
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varijeteta koji se razlikuju u opisnoj snazi [117]. Odavde proizilazi da je ontologija 
specifikacija apstraktnog modela podataka (konceptualizacija domena) koja je 
nezavisna od njege partikulame fonne. Ovde se ontologija diskutuje u kontekstu 
primene u inženjeringu softvera i baza podataka. Ontologija specificira vokabulari koji 
čine određene tvrdnje, koje mogu biti ulazi ili izlazi agent znanja (kao što je softverski 
program). Kao specifikacija interfejsa, ontologija obezbeđuje jezik za komunikaciju sa 
agentom. Agent koji podržava taj interfejs nije u obavezi da koristi termine ontologije 
pri internom kodiranju svoga znanja. 

4.5.1.2 Primena ontologija 

Ontologijom se formalno definiše skup tennina koji se koriste da bi se opisao i 
predstavio određeni domen, oblast znanja. Ontologije koriste ljudi, baze podataka i 
aplikacije koje imaju potrebu za zajedničkim korišćenjem informacija iz datog domena. 
Domen može biti specifična predmetna oblast ili oblast znanja poput medicine, 
proizvodnje uređaja, upravljanja nekretninama, upravljanja vladinim servisima [216], 
upravljanja finansijama. Istovremeno, ontologije mogu koristiti i određeni alati kojima 
se unapređuju veb-usluge, kao što su precizni veb-pretraživači, inteligentni softverski 
agenti i alati za upravljanje znanjem. U odnosu na znanje koje se modeluje u okviru 
ontologije, dolazi se i do opštih karakteristika ontologija, tako da razlikujemo sledeće 
tipove ontologija: 

• ontologije zasnovane na pravilima (generičke ontologije) - definišu 
terminologiju i koncepte koji su od značaja za krajnjeg korisnika, bez obzira da 
li je krajnji korisnik osoba ili korisnička aplikacija; 

• procesne (aplikativne) ontologije - definišu ulaze, izlaze, ograničenja, veze, 
pojmove i redosled informacija koji je značajan za određeni proces ili skup 
procesa. Obično sadrži sve neophodne podatke za modelovanje pojedinačnih 
domena znanja; 

• domenske (klasične) ontologije - definišu terminologiju i koncepte značajne za 
pojedinačne oblasti interesovanja (npr. elektronika, medicina, mehanika...); 

• interfes ontologije - definišu strukturu i sadržaj ograničenja značajnih za 
određene interfejse (npr., API (. Application Programming Interface), baze 
podataka...); 

• više ontologije. 

Pri definisanju neke ontologije, neophodno je opisati sledeće vrste koncepata: 

• klase - kojima se predstavljaju različiti domeni interesovanja; 

• veze - koje mogu postojati između klasa; 

• karakteristike (atributi) - karakteristike klasa; 

• ograničenja atributa - služe za proveru konzistentnosti postavljenih rešenja, ali i 
za dalje unapređenje pretraživanja i dolaženje do novih saznanja. 

Korišćenjem ontologija omogućuje se [8]: 

• zajedničko korišćenje razumljivih struktura informacija između ljudi i/ili 
softverskih agenata; 

• mogućnost ponovnog korišćenja domena znanja; 

• dokazivanje tačnosti pretpostavki; 

• odvajanje domena znanja od operativnog znanja; 
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• analiza domena znanja. 

Korišćenjem ontologija pretraživačke mašine prelaze sa tekućeg pristupa pretraživanja 
po ključnoj reči na pronalaženje sadržaja koji su sintaktički različiti ali semantički 
predstavljaju slične reči. 

Primer upotrebe ontologija na vebu mogu biti sajtovi za elektronsku trgovinu gde su 
ontologije potrebne jer omogućavaju [124]: 

• mašinski zasnovanu komunikaciju između prodavca i kupca; 

• vertikalnu integraciju tržišta, kada kompanija proširuje svoje poslovanje 
na nove oblasti koje pripadaju istoj proizvodnoj liniji; 

• upotrebu semantički istih termina koji se koriste na različitim prodajnim 
mestima. 

4.5.2 Primena ontologija u integraciji sistema 

Korišćenje ontologija kao mogućeg rešenja za problem semantičke interoperabilnosti 
intenzivno se istražuje. Ontologije se koriste za reprezentovanje semantičkih sadržaja 
izvora podataka koji se deklarišu u fonni koncepata, njihovih atributa i semantičkih 
veza. U gotovo svim ontološki zasnovanim integracionim pristupima ontologije se 
koriste za eksplicitni opis semantike poslovnih objekata. Generalno, mogu se 
identifikovati tri različita pristupa primene ontologije: centralizovani pristupi (pristupi 
zasnovani na jednoj globalnoj ontologiji), decentralizovani pristupi (pristupi zasnovani 
na višestrukim ontologijama) i hibridni pristupi. 

U centralizovanim pristupima, koji se zasnivaju na medijatorskoj arhitekturi, kao 
zajednički model podataka koristi se ontologija. Globalna ontologija reprezentuje skup 
koncepata koji egzistiraju u određenom domenu i pomoću njih opisuje semantičke 
sadržaje nekog poslovnog domena. Pristup podacima formuliše se u terminologiji 
globalne ontologije, a realizuje nad lokalnim izvorima podataka preko jasno definisanih 
semantičkih preslikavanja između globalne ontologije i šema lokalnih izvora podataka, 
slika 39. Korisnički upiti definišu se u terminima opisanih koncepata, a dobijeni 
odgovori na postavljene upite reprezentuju se preko instanci istih koncepata. 



Slika 39. Integracija preko jedne zajedničke ontologije 

Poznati pristup ove vrste ontološke integracije je SIMS (Sand Information Management 
for Decision Svstems). SIMS model aplikacionog domena opisan je u LOOM 
deskriptivnom logičkom jeziku. Ovaj model koristi se za opis sadržaja izvora podataka 
prvenstveno pomoću uspostavljanja is-a veza između lokalnih i globalnih koncepata. U 
SIMS-u se koriste dva jezika za definisanje upita: LOOM i podskup SQL-a koji sadrži 
operacije projekcije, selekcije i spajanja. 
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Pristupi koji se zasnivaju na jednoj globalnoj ontologiji mogu se primenjivati na 
integracione probleme, gde svi izvori podataka koji se integrišu obezbeđuju približno 
isti pogled na specifični domen. Međutim, ako jedan izvor podataka ima različit pogled 
na domen, tj. obezbeđuje drugi nivo granulamosti, usaglašavanje takvog izvora 
podataka sa globalnom ontologijom postaje težak zadatak. Takođe, pristupi koji se 
baziraju na jednoj globalnoj ontologiji osetljivi su na izmene u izvorima podataka jer 
impliciraju promene u globalnoj ontologiji i preslikavanjima sa lokalnim izvorima 
podataka. U decentralizovanim pristupima koji se zasnivaju na višestmkim 
ontologijama svaki izvor podataka opisan je pomoću sopstvene lokalne ontologije i 
između svakog para lokalnih ontologija definisana su ontološka preslikavanja koja 
identifikuju semantički slične ili ekvivalentne izraze iz različitih ontologija. Svaki izvor 
podataka razvija se nezavisno od drugih izvora i njihovih ontologija, slika 40. U 
ovakvoj ontološkoj arhitekturi izmene izvora podataka (dodavanje novih, modifikacija 
ili izbacivanje postojećih) jednostavne su i lake. 



Slika 40. Integracija zasnovana na višestmkim ontologijama 

Prednosti ovog pristupa su jednostavnost i fleksibilnost: ne zahteva se globalna 
ontologija i ontološkim preslikavanjima se upravlja lokalno. Međutim, odsustvo 
zajedničke ontologije čini proces poređenja različitih ontologija ekstremno teškim. Za 
prevazilaženje ovog problema uvedena su međuontološka mapiranja. Međutim, u praksi 
nije lako definisati međuontološka preslikavanja jer se mogu javiti različiti problemi 
vezani za semantičku heterogenost. Ovi pristupi, uopšteno govoreći, nisu previše 
skalabilni, jer se zahtevaju 0(n 2 ) ontološka mapiranja, gde je n broj ontologija. Zbog 
toga su nepodesni za velike ontološke sisteme (kao što je to, na primer, semantički veb). 
Jedan od sistema koji koristi decentralizovani ontološki pristup jeste OBSERVER. Ovaj 
ontološki integracioni sistem obezbeđuje jedinstvenu platformu za pretraživanje 
višestmkih ontologija. Ontologije se koriste za preslikavanja izraza u korisničkim 
upitima u odgovarajuće izraze definisane u dmgim ontologijama. Međuontološka 
preslikavanja definisana su pomoću posebne komponente IRL (Inter Ontological 
Relationship Manager). Korisnik bira jednu od ontologija iz sistema (koje su smeštene 
na ontološkom servem) i formuliše upit nad izabranom ontologijom. Ontološke 
translacije korisničkog upita obavljaju se preko IRL komponente. OBSERVER koristi 
deskriptivnu logiku za reprezentovanje i procesiranje ontologija. 

U hibridnim ontološkim pristupima pokušavaju se prevazići nedostaci pristupa 
zasnovanih na jednoj zajedničkoj ontologiji ili višestmkim ontologijama. Slično 
pristupima koji se zasnivaju na višestmkim ontologijama semantika svakog izvora 
podataka opisana je pomoću njegove sopstvene ontologije. Za upoređivanje lokalnih 
ontologija koristi se zajednički rečnik, slika 41. Zajednički rečnik definiše osnovne 
izraze domena koji se mogu kombinovati u cilju opisa mnogo složenije semantike izraza 
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u lokalnim ontologijama. Svaki izraz iz lokalnih ontologija opisuje se pomoću osnovnih 
koncepata tako da je upoređivanje izraza lakše nego u višestrukim ontologijama. 



Slika 41. Hibridni ontološki pristup integraciji 

Ovaj pristup kombinuje prednosti oba prethodna pristupa: reducira broj preslikavanja i 
omogućava fleksibilno upravljanje preslikavanjima u lokalnom kontekstu. Prednost 
hibridnog pristupa je u tome što se novi izvori podataka mogu lako dodati bez 
modilikacije u preslikavanjima ili zajedničkom rečniku. Korišćenje zajedničkog rečnika 
omogućava poređenje lokalnih ontologija. Nedostatak hibridnih pristupa je u tome što 
se postojeće ontologije ne mogu lako ponovo koristiti jer su u vezi sa zajedničkim 
rečnikom [6]. 
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5 Razvoj modela interoperabilnog elektronskog 
poslovanja platnih sistema zasnovanog na ontologijama 

Svaka poslovna transakcija indukuje jednu ili više finansijskih transakcija (FT). Vrlo je 
čest slučaj da se poslovna transakcija u nekom segmentu ne naplaćuje poslovnom 
partneru. I inteme poslovne transakcije imaju svoju cenu koja se, po pravilu, ne 
naplaćujuje ali se prilikom izračunavanja ukupne cene poslovnog procesa i ona uzima u 
obzir kao trošak. U elektronskom poslovanju generisanjem eksternih finansijskih 
transakcija vrši se automatizacija poslovnih procesa [73]. I u elektronskom poslovanju 
generisanjem internih finansijskih transakcija za naknadu troškova procesiranja može se 
izvršiti automatizacija kalkulacije ukupnih troškova poslovnih procesa. 

5.1 Procesi elektronskog poslovanja platnog sistema 

Za model sistema elektronskog poslovanja platnih sistema (EPPS) od interesa su 
instmmenti plaćanja, podaci, učesnici i procesi [17]. Sistemi plaćanja na osnovu kojih 
nastaje finansijska transakcija i konkretna okruženja u kojima je nastala finansijska 
transakcija nisu predmet ovog rada. 



Osnovni procesi elektronskog poslovanja platnih sistema su [95]: 

1. proces legalizacije razmene i procesiranja finansijskih transakcija: 

1.1. proces stvaranja zakonskog okmženja za primenu instmmenata platnog 
prometa; 

1.2. proces stvaranja poslovnog okmženje za primenu instrumenata platnog 
prometa; 

2. proces pripreme izvršenja finansijske transakcije; 

3. proces akvizicije informacija o finansijskoj transakciji; 

4. proces pretprocesiranje finansijske transakcije; 
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5. proces procesiranja finansijskc transakcije; 

6. proces postprocesiranja finansijske transakcije; 

7. proces pripreme za distribuciju; 

8. proces prosleđivanja poruke. 

Na slici 42. prikazan je sažeti model elektronskog poslovanja platnih sistema. 

5.1.1 Instrumenti platnog prometa 

Instrumenti platnog prometa su [133], [154]: 

• nalog za prenos; 

• nalog za naplatu; 

• nalog za uplatu; 

• nalog za isplatu. 

Nalog za uplatu i nalog za isplatu trenutno su gotovinski, odnosno materijalni i ne 
postoji globalni model dematerijalizacije novca ako se izuzmu lokalne inicijative [24]. 
U tom kontekstu može se razmatrati emiter novčanih vrednosti, u većini slučajeva 
centralna banka države i emisija novca koja se odlikuje brojem novčanica koje emituje, 
vrednošću novčane jedinice i identifikacijom novčane jedinice, odnosno serijskim 
brojem novčanice i vlasnikom emitovane jedinice. 

Ukoliko emiter novčane vrednosti vodi evidenciju tokom životnog ciklusa novčane 
jedinice o novčanoj jedinici i vlasniku novčane jedinice, može se u tom kontekstu i 
nalog za uplatu i nalog za isplatu posmatrati u svetlu elektronskog poslovanja platnih 
sistema. Po pitanju naloga za prenos u elektronskom poslovanju platnih sistema 
standardizovan je pod nazivom „Credit Transfers“ ili pod drugim nazivom ,JDirect 
CrediC, a nalog za naplatu je standardizovan pod nazivotn ,JDirect DebiC ili pod 
drugim dotnaćim uobičajenim nazivotn „direktno zaduženje“ [140]. 

5.1.2 Učesnici u sistemu elektronskog poslovanja platnih sistema 

Učesnici u sistemu elektronskog poslovanja platnih sistema su [154]: 

• Retail korisnici (učesnici u prometu „па tnalo“): pravna i fizička lica; 

• druge finansijske institucije (učesnici u prometu „па veliko“): agenti plaćanja, 
posredničke kuće, klirinške kuće za neto poravnanje finansijskih transakcija, 
kuće za poravnanje hartija od vrednosti, kreditni biroi, osiguravajuća i 
reosiguravajuća društava, brokerske kuće i ovlašćena lica i institucije za 
obavljanje poslova platnog prometa; 

• banke kod kojih su deponovana sredstva pravnih, fizičkih lica i drugih 
finansijskih organizacija na osnovu kojih se obavljaju finansijske transakcije tih 
učesnika; 

• centralne banke sa sistemima za bruto i neto poravnanje finansijskih transakcija: 
RTGS sistem, klirinški sistem, sistemi za poravnanje tneđunarodnih finansijskih 
transakcija; 

• tneđunarodne finansijske institucije: inostrane klirinške kuće, inostrane banke 
koje su učesnici u tneđunarodnim sistemima za poravnanje, inostrane 
rneđunarodne organizacije; 

• tneđunarodni fondovi tneđu kojima je i tneđunarodni monetarni fond MMF. 
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5.1.3 Osnovni procesi elektronskog poslovanja platnih sistema 

Proces legalizacije razmene i procesiranja finansijske transakcije sastoji se od 
aktivnosti, prikazanih na slici 43. i slikama sa dijagramima aktivnosti slika 44. i slika 
45: 

a. ) Procesa stvaranja okruženja za zakonsku primenu instrumenata platnog 
prometa, odnosno potpisivanja odgovarajućih zakonskih dokumenata koji definišu 
proces plaćanja, na primer: 

• ugovora sa bankom o otvaranju računa; 

• potpisivanja prihvatanja cenovnika platnih usluga; 

• potpisivanj a protokola plaćanj a; 

• potpisivanja potvrde o preuzimanju potrebnih sredstava za izvršavanje iniciranja 
transakcije; 

• potpisivanje ugovora sa poslovnim partnerom o mogućnostima i uslovima 
iniciranja finansijske transakcije direktnog zaduženja i drugo. 

b. ) Procesa stvaranja okruženja za poslovnu primenu instrumenata platnog 
prometa, odnosno definisanja: 

• kanala za razmenu finansijskih transakcija; 

• načina sigume razmene finansijskih transakcija; 

• neporecive razmene finansijskih transakcija; 

• potpisivanja protokola o korišćenju informatičkih resursa; 

• prihvatanja tarifa za razmenu finansijskih transakcija. 



Slika 43. Poslovni procesi plaćanja: Legalizacija 
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Proces pripreme izvršenja finansijske transakcije, slika 46. i dijagram aktivnosti na 
slici 47, za nadređene i podređene finansijske sisteme se sastoji od: 

• otvaranja komunikacionih kanala za prihvatanje informacija o finansijskim 
transakcijama; 

• potrebne prijave na nadređene sisteme; 

• prihvatanja prijave na sistem podređenih sistema za razmenu informacija o FT; 

• verifikacije učesnika za razmenu; 

• prihvatanja osnovnih informacija potrebnih za razmenu i procesiranje; 

o dnevne tarife; 
o kursne liste; 
o druge servisne informacije. 


2. Priprema za izvršenje 
finansijske transakcije 


2.1. Otvaranje komunikacionih kanala 


2.2. Prijava na nadredeni sistem 


2.3. Prihvatanje prijave podređenog sistema 


2.4. Verifikacija učesnika 


2.5. Razmena servisnih informacija 


т 


Nadređeni sistemi 


Podređeni sistemi 


Slika 46. Poslovni procesi plaćanja: Priprema za izvršenje FT 
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Proces akvizicije informacija o finansijskoj transakciji, slika 48. i dijagram 
aktivnosti na slici 49, sastoji se od: 

• prijema odgovarajuće standardizovane poruke koja u sebi sadrži: 

o informacije o sebi; 
o sadržanim instrukcijama; 
o transakcijama; 

• skladištenja originalne poruke sa odgovarajućim elementima; 

o za proveru pošiljaoca; 
o sadržajaporuke; 

• dekripcija (dešifrovanje) poruke; 

• provere pošiljaoca poruke; 

• provere nepromenjenosti sadržaja poruke; 

• provere sintakse poruke; 

• provere semantike poruke; 

• provere osnovnih poslovnih pravila vezanih za primljenu poruku; 

• slanjapotvrde 

o prijema ukoliko je poruka u redu ili odbijanju poruke sa razlogom 
odbijanja. 


3. Akvizicija informacija o FT 


3.1. Prijem poruke 


3.2. Skladištenje originalne poruke 


3.3. Dekripcija poruke 


3.4. Provera poruke 


3.4.1. Provera pošiljaoca poruke 


3.4.2. Sintaksna provera poruke 


3.4.3. Semantička provera poruke 


3.4.4. Provera osnovnih poslovnih pravila 


3.5. Generisanje potvrde prijema 


Slika 48. Poslovni procesi plaćanja: Akvizicija informacija o FT 
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4 . Pretprocesiranje FT 


4.1. Semantička provera 


4.2. Provera poslovnih pravila 


4.3. Skladištenje podataka za procesiranje 


4.4. Generisanje stavki 

4.4.1. Stavke za praćenje 


4.4.2. Stavke za statistiku 


4.4.3. Stavke za izveštavanje 


Slika 50. Poslovni procesi plaćanja: Pretprocesiranje FT 
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5. Procesiranje FT 


5.1. Izdvajanje podataka o FT 


5.2. Izvršenje zadatih operacija za FT 


5.3. Skladištenje rezultata procesiranja FT 


4.4. Generisanje stavki 

4.4.1. Stavke za praćenje 


4.4.2. Stavke za statistiku 


4.4.3. Stavke za izveštavanje 


v 

Slika 52. Poslovni procesi plaćanja: Procesiranje FT 

Proces procesiranje finansijskih transakcija uključuje izvršenje potrebnih operacija 
nad informacijama o transakciji, slika 52. i dijagram aktivnosti na slici 53, i sastoji se 
od: 

• izdvaj anj a podataka finansij ske transakcij e; 

• skladištenja podataka o finansijskoj transakciji; 

• izvršenja odgovarajućeg skupa operacija nad finansijskim transakcijama koje 
zavise od: 

o vrste organizacije u kojoj se finansijska operacija obavlja; 
o zakonske regulative koja propisuje operacije koje se trebaju obaviti; 
o položaj a institucij e koj a obavlj a finansij sku transakciju; 
o funkcij e institucij e koj a obavlj a finansij sku transakciju; 

• skladištenja rezultata procesiranja finansijske transakcije i u zavisnosti od tipa 
finansijske transakcije i vrste procesiranja koja: 

o može biti izvršena odmah ili 
o može biti odložena; 

• generisanja stavki za potrebe praćenja 

o izvršavanja finansijske transakcije; 
o statistike; 

o izveštavanja o finansijskim transakcijama. 
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V 
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Slika 57. Poslovni procesi plaćanja: Prosleđivanje poruke 

Proces prosleđivanja informacija o finansijskoj transakciji prikazan na slici 57. i 
kroz zajednički dijagram aktivnosti procesa pripreme za distribuciju i procesa 
prosleđivanja na slici 58, sastoji se od: 

• iniciranja slanja; 

• prijema poruke kod primaoca; 

• potvrde o 

o prihvatanju poruke o pri čime se proces završava; 
o ili potvrde o odbijanju poruke; 

■ kada se originalna poruka o finansijskoj transakciji označava kao 
poruka sa greškom; 

■ inicira proces reklamacije u svom sistemu u odnosu na poruku o 
grešci. 
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Prikaz modela elektronskog poslovanja platnih sistema prikazan je na slici 59. i sačinjen 
od podmodela opisanih u prethodnom tekstu. 


N 

A 

D 

R 

E 

Đ 

E 

N 

I 


S 

I 

S 

T 

E 

M 

I 


Legalizacija procesa razmene i procesiranja FT 


Stvaranje zakonskog okruženja za primenu instrumenata platnog prometa 


Potpisivanje protokola 

Potpisivanje ugovora 

Potpisivanje cenovnika za FT 

Preuzirnanje alata za 
izvršavanje FT 

Stvaranje poslovnog okruženja za primenu instrumenata platnog prometa 

Definisanje kanala 
razmene F T 

Definisanje bezbednosti 
i neporecrvosti 

Potpisivanja protokola o 
IT resursima 

■ ■ ■ 

Potpisivanja cenovnika 
razmene FT 


Priprema za izvršenje finansijske transakcije 


Otvaranje 

komunikacionih 

kanala 


Prijava na nadređeni 
sistern 


Prilivatanje prijave 
podređenog sisterna 


Verrfikacija učesnika 


Razrnena servisnih 
informacija 


Akvizicija informacija o FT 


Prijern poruke 


Skladištenje 
originalne poruke 


Dekripcija poruke 


Provera poruke 


Provera pošiljaoca 

Sintaksna provera 

poruke 

poruke 


Semantička provera 

Provera osnovnih 

poruke 

poslovnih pra/ila 


Generisanje potvrde 
prijenta 


Pretprocesiranje FT 


Semantička 

provera 


Provera 

poslovnih 

pravila 


Sldadištenje 
podataka za 
procesiranje 


Procesiranje FT 


Izdvajanje 

podataka 

oFT 


Izvrsenje zadatih 
operacija za FT 


Skladištenje 
rezultata 
procesiranja FT 


Postprocesiranje FT 


Izdvajanje podataka 

Priprema za 

za slanje 

distribuciju 


Generisanje stavki 


Za praćenje 


Za statistiku 


Za izveštavanje 


Priprema za distribuciju 


Izdvajanje podataka 
o FT za slanje 


Fonniranje 

instrukcije 


Formiranje poruke 


Formiranje tela 
pomke 


Adresiranje 

рошке 


Potpisivanje 

рошке 


Kriptovanje 

poruke 


Skladištenje poruke 


Prepuštanje poruke sistemu za transport 


Prosleđivanje poruke 


Iniciranje slanja poruke 


Označavanje ispra/nosti рошке u 
sisternu 


Prijern potvrde 


Slika 59. Struktura modela EPPS 


Poslovni procesi plaćanja odvijaju se po termin planu. Tennin plan može da sadrži i 
dodatna procesiranja finansijskih transakcija koja su asinhrona u odnosu na akviziciju 
poslovnih transakcija, kao što je, na primer, zakonska obaveza slanje izvoda. Slanje 
izvoda započinje u procesu Procesiranje FT, a završava se procesom Prosleđivanje 
poruke. 

Model EPPS može da se sagleda, osim sa logičkog stanovišta, i sa fizičkog stanovišta. 
Model je zasnovan na sledećim informatičkim resursima: 
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• hardverskoj infrastrukturi; 

• komunikacionoj infrastrukturi; 

• osnovnom sistemskom softveru; 

• baznim sistemskim komponentama; 

• aplikativnim komponentama; 

• sistemima za upravljanje bezbednošću; 

• sistemima za monitoring; 

• sistemima za upravljanje; 

• sistemima za nadzor; 

• sistemima za fizičku zaštitu; 

• sistemima za izveštavanje; 

• Help Desk sistemom; 

• sistemskom podrškom; 

• pomoćnim sistemima za obezbeđivanje neprekidnog napajanja električnom 
energijom. 



Slika 60. biterakcija EPPS sa drugim osnovnim sistemima 


Sistem elektronskog poslovanja platnih sistema je u interakciji sa sledećim sistemima, 
prikazanim na slici 60: 

• sistemom za razmenu poruka; 

• registracionim telom; 

• infrastrukturom za podršku PKI i sertifikacionim telom; 

• drugim poslovnim sistemima elektronskog poslovanja organizacije. 

Prilikom modeliranja sistema elektronskog poslovanja platnih sistema posebnu pažnju 
je potrebno posvetiti elementima kontinualnog poslovanja i na adekvatan način 
obezbediti sajt u slučaju iznenadnog prekida rada osnovnog sajta i sajt u slučaju 
nemogućnosti rada osnovnog sajta u katastrofalnim uslovima. Napredniji sistemi 
elektronskog poslovanja platnih sistema sadrže još jednu instancu osnovnog sistema na 
kome mogu da se izvode operacije u laboratorijskim uslovima. 
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5.2 Model podataka 

Model podataka proizilazi is strukture standardizovane poruke [17], [44]. Izučavanjem 
strukture IS020022 poruka [98] SWIFT ML standardnih poruka [205],[207], IS020022 
poruka preslikanih u XML strukturu, EANCOM [15], [81], standardnih poruka lanaca 
snabdevanja [54], [82] meteo poruka (poruka za akviziciju i distribuciju 

hidrometeoroloških podataka), TWIST poruka [213] koje su agregacija finansijskih 
transakcija i transakcija sistema lanaca snabdevanja i drugih, uočena je analogna 
struktura poruke. Model poruke može biti predstavljen XML strukturom (XSD šemom). 
Struktura XML šeme koja se preslikava u relacionu strukturu baze podataka predstavlja 
generički model podataka koji u zavisnosti od upotrebe može da se transfonniše u 
ekvivalentne strukture. U nastavku je prikazana generička struktura poruke sa 
odgovarajućim elementima XML šeme koji se preslikavaju u atribute relacione 
strukture [18]. Navedena struktura poruke, prikazana na slici 61, može se koristiti kod 
opisivanja elemenata sistema. 

Poruke nastaju u sistemima gde postoje potrebe razmene informacija o poslovnim 
transakcijama. Informacije o transakcijama se primaju iz različitih segmenata - 
podsistema, ali se vrši razmena i između različitih poslovnih tipova sistema. Put 
transakcije kod svih učesnika u procesima plaćanja isti, determinisan adresom i 
poslovnim sadržajem poruke. 



Slika 61. Struktura finansijske poruke 

Na slici 61. prikazana je struktura finansijske poruke [14]. Poruka se sastoji od svog 
zaglavlja i jezgra, odnosno tela poruke. U opštem slučaju, poruka može da ima više 
jezgara, koji čak ne moraju da pripadaju ni istim standardima poruka. Svako jezgro 
poruke može da se sastoji odjednog ili više dokumenata. Dokumentaciono jezgro sadrži 
informacije koje ga i čine dokumentom: na jedinstven način može se odrediti 
verodostojnost dokumenta, onog koji je taj dokument izdao, zbog čega je taj dokument 
izdat i slično. Dokument se u suštini sastoji od instrukcija (CRUD) sa kojim se kreira 
nova instanca nekog poslovnog objekta ( create ), daje infonnacije o nekom poslovnom 
objektu ( read ), vrši njeno ažuriranje ( update ) ili povlačenje ( delete ) [27]. Transakcija se 
sastoji od operacija koje treba obaviti da bi se ona ostvarila. Instrukcija može biti 
proizvoljan broj [38]. Poruka se sastoji od zaglavlja poruke i tela poruke, čija je 
specifikacija atributa u nastavku: 
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<Poruka> 

<Zaglavlje poruke> 

<Identifikacija početka zaglavlja рошке> 
<Identifikacija standarda poruke> 
<Identifikacija tipa рошке> 

<ldentifikacija pripadajućeg sistema> 
<Jedinstvena identifikacija poruke> 
<Adresa Pošiljaoca poruke> 

<Adresa Primaoca poruke> 

<Datum slanja> 

<Poslovno pravilo zaglavlja> 

<Telo poruke> 

<Identifikator početka tela рошке> 
<Identifikacija standarda tela poruke> 
<ldentifikacija tipa tela poruke> 
<Jedinstvena identifikacija tela poruke> 
<Sadržaj tela poruke> 
<Dokument l-n> 

<Poslovno pravilo tela poruke> 

Struktura dokumenta je sledeća: 

<Dokument> 

<Identifikator početka dokumenta> 

<Identifikacija standarda dokumenta> 
<Identifikacija tipa dokumenta> 

<Jedinstvena identifikacija dokumenta> 

<Sadržaj dokumenta> 

<lnstrukcija 1 - n> 

<Poslovno pravilo dokumenta> 

Instrukcija ima sledeću strukturu: 

<Instrukcija> 

<Identifikator početka instrukcije> 

<Identifikacija standarda instrukcije> 

<Identifikacija tipa instrukcije> 

<Jedinstvena identifikacija instrukcije> 

<Sadržaj instrukcije> 

<Transakcija 1 — n> 

<Poslovno pravilo instrukcije> 

Transakcija ima sledeću strukturu: 

<Transakcija> 

<Identifikator početka transakcije> 

<Identifikacija standarda transakcije> 

<Identifikacija tipa transakcije> 

<Jedinstvena identifikacija transakcije> 

<Sadržaj transakcije> 

<Objekatl> 

<Poslovna pravila Objektal> 

<Povezani objekat l-n> 

<Poslovna pravila povezanih objekata l-n> 

<operacija 1 - n (CRUD)> 
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Na slici 62. do slike 64. prikazana je XML struktura modela poruke sa opisanim 
elementima modela. Na slikama 65. i 66. prikazana je struktura poslovnog pravila [9] 
poruke i konkretan primer pravila. 


C xrnl 

. C #comment 

S. Poruka 

C xsi:noNamespaceSchemaLocation 

. C xmlns:xsi 

B. ĆJ Zaglavlje_Poruke 

. C Identifikacija_Tipa_Poruke 

C Identifikacija_Standarda_Poruke 
C Identifikacija_Pripadajuceg_Sistema 
C Identifikacija_Pocetka_Zaglavlja_Poruke 

S. C Datum_Slanja 

И C Adresa_Primaoca_Poruke 

(3. C Adr e s a_P o s i 1 j o c a_P o r uke 

И . C Jedinstvena_Identifikacija_Poruke 

Š tJ Telo_Poruke 

C IdentifikacijaTipa_Tela_Poruke 
C Identifikator_Standarda_Te1a_Poruke 

. C Identifikator_Pocetka_tela_Poruke 

C Jedinstvena_Identifikacija_Tela_Poruke 

s. tJ Dokument 

j. C Identifikator_Tipa_Dokumenta 

. C Identifikator_Pocetka_Dokumenta 

C Identifikator_standarda_dokumenta 

. C Jedinstveni_Identifikator_Dokumenta 

I B icJ Instrukcija 

C Identifikator_Pocetka_Instrukcije 
C Jedinstvni_Identifikator_Instrukcije 
C Identifikator_Tipa_Instrukcije 
C Identifikator_Standarda_Instrukcije 
B ĆJ Transakcija 

C Identifikator_Standarda_Transakcije 

. C Identifikator_Tipa_Transakcije 

. C Identifikator_Pocetka_Transakcije 

C Jedinstvena_Identifikacij a_Transakcij e 

(3. C Objekat 

Š. C Poslovno_Pravilo_Objekta 

Š. C Poslovno_Pravilo_Objekta 

Š . C Povezani_Objekat 

Š. C Povezani_Objekat 

Š. C Poslovno_Pravilo_Povezanog_Objekta 

Š . C Poslovno_Pravilo_Povezanog_Objekta 

ј B. ĆJ Operacija 


|Operat ion Create 


j Ш . Q Transakcija 

Š ĆJ Instrukcija 
B ĆJ Dokument 


Slika 62. XML struktura modela poruke 
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& 


Zaglavlje_Poruke J, 



Jedinstvena ldentifikacija Poru... 

:ype ZaglavljePoruke П 



type |xs:string 


ldentifikacija Pocetka Zaglaulja... 


use [reguired 


ldentifikacija_Standarda_Poruke 

ise | reguired 


ldentifikacija_Tipa_Poruke 


~ I reguired 


ldentifikacija_Pripadajuceg_Sist... 

:: . reguired 


чЗ 3- 


DatumSlanja 

. [■? [xs:dateTime 


Adresa Primaoca Poruke 


Adr esa _Posiljoca_Por uke 


MyBiz Business Rules 


! Poslovno_Pravilo_Zaglavlja X / ^ s—, I 

I: i •? j T_My Biz_Business_Rules _T; j 4 - ' ] 

0..П | 

L. 


Business_Rule 

Business_Rute | | I 




[уре [xs:strjng \ 


Slika 63. XML struktura modela poruke - grafički prikaz 


Гт$1оропји« 


[TeioPortKe 


Ч=^Ј 


r J$dinitv$na M$ntiflh3cij3 T$ia Pjr... 


xg^trng 


Dohumant 




¥. 


Dohumanat 

— | И 3tr/tX/t!.5 | 


-J$dlnitv$nl idsntflhator Dohumenta 


ЧЕЕН 


l'. e »ytfl>g 


hitoihcija 
to ližtrihcla 4 


hitruhclja 

— |E) | 


3i 


=J$dln itvnl_U$ntiflhator_h »truhclje 
ЛТе I xg atri»g 


_| Traniahclja 


— |И агтх,'* :- \ 



=CbJ$hat 


tf* ОЦеКа) 


=Jedin itv$na_«$ntiflhaci Ја_тгап iahci.. 


i у> g^trlig 


; Poilovno ffflvllo ObJ»hta 
П.Д 

чееН. ;=Pov$2ani_ct'jHhat Г; 

;у* { PoKzaiObjejatJ' 


Poilovn o_FYavllo_Pov$anog _Obj$... r4 

jjjs * г . _ 


_! Poilovno_FTavilo_hitnjhcij$ Л 

»Je« _ ^_!j 


_! Poilovno_FTaviio_Dohum$nta , 

!jf?J T-.4V? ?. В .Ч _ 


_! Poilovno_FTavllo_T$la_PoruhH Л 


Slika 64. XML struktura modela poruke, telo poruke 
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I T_MyBiz_Business_Rule: 


T Business_Rule 


Му Bi z Busi ness Rul e< 


T My B iz B usi n ess R u I es 




Business Rule 


pž | T Business Rule 




Р" ] T Rule Nam 


: Rule Version 


i 


: Busi ness Acti on Na me 




Start_date 

'pe | T Start date 


: Retire_date 
'pe | T Retire date^ 


Vpe I 


T Precedence 


: Access level 


pe | T Access leveT 


'•pe | T Scope 


: Success Acti on 


_ 


T Success Action 


Success Rul e Na me 




T Success Rule Name 


: Failure Action 


Т1 


T Failure Action 


Fai I ure Rul e Na me 


Т1 


T Failure Rule Name 


'pe]T Language 




уре | xs:string 


: Oracle PLSQL 


','ре |xs:string 


tvP* 1 




'pe | T_C_Source 


L_- 


“Signature 

type 

xs:base64Binary 

derivedBy 

extension 


Slika 65. XML struktura modela poslovnog pravila u strukturi poruke 


29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 


42 


<?xml version="1.0"?> 

B<MyBiz_Business_Rules xmlns:xsi="http://www. w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation=" 
c:\DOCUME~1\babics\desktop\mybiz_business_rules.xsd"> 

© <Business_Rule> 

<Rule_Name>Discount_Rule_30Percent</Rule_Name> 

<Rule_Version>1.0</Rule_Version> 

<Business_Action_Name>Calculate_Discount</Business_Action_Name> 

<Start_date>12FEB2001</Start_date> 

<Retire_date>31DEC2002</Retire_date> 

<Precedence>15</Precedence> 

<Access_level>Salesreps</Access_level> 

<Scope>Enterprise</Scope> 

<Success_Action>Terminate</Success_Action> 

<Success_Rule_Name/> 

<Failure_Action>Continue</Failure_Action> 

<Failure_Rule_Name/> 

© <Language> 

© <English> 

i Orders greaterthan 500 units receive a 30% discount Iftotal stock is greaterthan 10,000 units. 
г </English> 

0 <Oracle_PLSQL> 

procedure discount_rule_30percent(quantity_ordered in number, 

quantity_on_hand in number, 

discount inout number, 

success_action out varchar, 

failure_action out varchar) is 

begin 

if quantity_on_hand > 10,000 and 
quantity_ordered > 500 then 
discount := .30; 
success_action := 'Terminate'; 
else 

failure_action := 'Continue'; 

end if; 

end; 

|- </Oracle_PLSQL> 

© <C xmlns:xlink="http://www.w3.org/1999/xlink"> 

I <C_Source type="simple" href="Discount_Rule_30Percent.xml" role="http://www.mybiz.com/source/c" actuate="onRequest"/> 
</C>" 

</Language> 

</Business_Rule> 

<Signature ld=''Discount_Rule_30Percent" xmlnsi="http://www. w3. org/2000/09/xmlsig#"> 

UjBsR09EbGhjZDdTQUxNQUFBUUNBRU1tQ1 pOdUI GUXhEUzhi</Signature> 

1 </MyBiz_Business_Rules>| 





Slika 66. Primer konkretnog poslovnog pravila u poruci 
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Business_Rule 

| Rule_NarrE 
| Rule_Version 
| Business_AcCon_Narre 
j Start_date 
j Retire_date 
J Precedence 
Acoessjevel 

_| SoDpe 

| Sucoess_Acdon 
J Succe ss_Rii e_Na me 
| Failure_AcCon 
J Faiure_Rule_Narre 
Business_Rule_Id 

_| Poslovno_Pravito_Zaglavlja_Id 

| Poslovno_Pravito_Objekta_Id 
J Poslovno_Pravito_Poveza nog_Objekta_Id 
| Poslovno_Pravito_Instrukcije_Id 

_| Poslovno_Pravito_DDkurrenta_Id 

_| Po5lovno_Pravito_Tela_Ftoruke_Id 


Operacija 

| Operadon_Qeate 
_Ј Operadon_Read 
| Operadon_Update 

_| Operadon_Deiete 

■ Transatajajd 


Poslovno_Pravilo_Povezanog_Objekta 

| Signature 

*g| Postovno_Pravlo_Ftovezanog_Objekta_Id 
_| Transakdjajd 


Poslovno_Pravilo_Objekta 

_| Signature 

Ftostovno_Pravio_Objekta_Id 
■ Transakcijajd 


Transakcija 

| Identifikator_Pocetka_Transakdje 
| Idendfikator_Standarda_Transakcjje 
| Identifikator_Tipa_Transa kđje 

_| Jedinstvena_Idendfikadja_Transakdje 

| Objekat 

_| Ftovezani_Objekat 

*ј?| Transakdjajd 
J Instrukcijajd 


Zaglavlje_Poruke 

Idendfitecija_Pocetlca_Zaglav(ja_Poruke 
Idendfikadja_Standarda_Ftorul« 

Ide ndfi kadja_Tipa_Poruke 
Ide ndfi kadja_Pripa daj uoeg_Sstema 
Jed nstve najdendf ika aja_Ftoru I« 
Datum_Sanja 
Adresa_PrirrBoca_Poruke 
Adresa_Posi(joc 2 _Ftorute 
Zaglavlje_Poruke_Id 
Porukajd 



Cw' — 

CO'- 


Language 


English 


SQL 


Orade_PLSQL 


MS_SQL 


languagejd 


Business_RuleJd 



| Туре 
j Role 
J Href 
| Actuate 
■ Languagejd 


Poslov no_Pravilo_Zagl avl ja 

| Sgnature 

Ptoslovno_Pravito_Zaglavtja_Id 
J Za gla vlje_Poruke Jd 


Instrukcija 


Idenbfikator_Pocetka_Instrukqje 


Idenhfikator_Sta ndardajnstrukaje 


Idenbfikator_Tipa Jnstrukdje 


Jedi nstv nijdentf ikatorj nstrukdje 


Instrukdja Jd 


Dokurrentjd 



Poslovno_Pravilo_Instrukaje 

| Sgnature 

У| Postovno_Pra viojnstrukdjeJd 
Instrukajajd 


Dokument 

Idendf ikattor_Ftooetka_Dokune nta 
| Idendfikattor_standarda_dokumenta 
| Idendfikator_Tipa_Dokumenta 
| J ed nstve rtjde ndfi kator_Dokurrenta 
9| Dokumentjd 
J Telo_Poruke_Id 


Telo_Poruke 

| Idendfikator_Pooetka_tela_Poruke 
| Identfikator_Standarda_Tela_Poruke 
| IdentfikaajaTipa_Tela_Ftoruke 
| Jednstvena_Idenfifikadja_Tela_Poruke 
ff| Teto_Ftorul«_Id 
| Porukajd 


Poslovno_Pravilo_Dokumenta 

| Signature 

9| Poslovno_Pravito_Dokune ntajd 
J Dokumentjd 


Poslovno_Pravilo_Tela_Poruke 

Signature 

$ Poslovno_Pravito_Tela_Ftoruke_Id 
Telo_Poruke_Id 


Slika 67. Relaciona šema poruke sa poslovnim pravilom 

Model poslovnih pravila može se predstaviti uz pomoć XML strukture šema poruka 
koje opisuju sistem [16], [44]. Mogu se implementirati u standard zajedno sa strukturom 
podataka za razmenu. Na taj način mogu da se integrišu sistemi koji ne poznaju 
strukturu poruka i poslovna pravila koje će biti, u zavisnosti od ovlašćenja koja ima 
sistem koji šalje poruke u sistem koji prima poruke, primenjena u ishodišnom sistemu. I 
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ovde se struktura XML šeme preslikava u relacionu strukturu baze podataka, ali i 
primenjuje izvorno poslovno pravilo koje je poslato uz poruku [222], [114]. 

Sistemi koji su u nadređenom položaju mogu na ovaj način, nakon sticanja sistemskih 
uslova, da zadaju sisteme na podređenim lokacijama, dok bi podređenim lokacijama 
bilo dovoljno da navedu identifikaciju poslovnog pravila. Sistemi sa definisanim 
poslovnim pravilima u porukama složeniji su za zadavanje i upravljanje, ali ne 
zahtevaju komplikovan sistem za podršku na ishodišnoj lokaciji. Struktura poslovnog 
pravila: Poslovno pravilo(ID pravila; Ime pravila; Verzija pravila; Iine poslovne akcije; 
Datum početka; Datum isteka; Prioritet; Nivo pristupa; Opis; Akcija posle uspešne 
primene; Naziv akcije nakon uspeha primene; Akcija posle neuspešne primene; Naziv 
akcije nakon neuspeha primene; Jezik), Potpis. Poslovna pravila se ogledaju i u drugim 
ograničenjima sistema, koji se implementiraju nad perzistentnim elementima sistema. 
Na primer, Identifikator dužnika u domaćem platnom prometu mora da bude dužine 
osam karaktera ukoliko je u pitanju pravno lice, odnosno 13 ukoliko se radi o fizičkom 
licu - preduzetniku. Na slici 67. prikazana je relaciona šema poruke sa poslovnim 
pavilima instance poslovnog pravila prikazana na slici 65. 

5.3 SEPA model procesa 

Credit Transfers šema evropskog saveta za plaćanja [70] ima za cilj da uspostavi 
pravila i standarde međubankarskog poslovanja [96], [97] po pitanju upravljanja SEPA 
Credit Transfers-om kao instrumentom plaćanja radi ostvarenja interoperabilnosti [60] 
u komunikaciji i razmeni informacija o novčanim transferima. Takođe, šema naglasak 
stavlja na usvajanje otvorenih standarda kako bi se olakšala integracija među 
bankarskim sistemima [69]. 

Evropski savet za plaćanja u sklopu ove šeme obavezuje banke da referentne 
informacije o plaćanju ( remittance reference information ) prosleđuju neizmenjene kroz 
bankarske sisteme [188], od nalogodavca do korisnika [68]. EPC smatra da će time 
proces automatskog poravnanja računa biti značajno pojednostavljen. Šema je 
primenjiva u okviru SEPA zone, koju predstavlja 25 EU zemalja, kao i Island, 
Lihtenštajn, Norveška i Švajcarska [66]. Tajnost podataka o SEPA Credit Transfers-u 
mora biti garantovana i, po želji vlasnika platnog računa, može biti dodatno zaštićena 
šifrovanjem. Dijagram na slici 68, preuzet iz EPC125-05 dokumenta, predstavlja opšti 
pogled na proces Credit Transfers -а. Zahtev za korišćenje servisa (servisa za realizaciju 
instrukcija zadatih nalogom za transfer) inicira se od strane Nalogodavca, koji želi iz 
nekog razloga da izvrši transfer sredstava Korisniku sredstava. Platni servis, u domenu 
banke, prihvata osnovni zahtev. Da bi ovaj zahtev za prenosom sredstava bio 
realizovan, banka zadužuje račun Nalogodavca (koji mora da ima sredstva neophodna 
za namirenje iznosa na koji će biti odobren račun Korisnika) obezbeđuje dodatne 
informacije potrebne da bi se transfer obavio. Banka Nalogodavca treba da ustanovi da 
li Nalogodavac ima potrebna sredstva ili dovoljno sredstava sa kojim se može izvršiti 
Credit Transfers, da ustanovi da nalogodavac postupa u skladu sa svojim ovlašćenjima i 
da Credit Transfers ne krši ni jedan važeći zakon, regulative ili neki drugi uslov, 
uključujući uslove određene od strane banke Nalogodavca. Tada će banka Nalogodavca 
izvršiti plaćanje i nakon toga obavestiti Nalogodavca. Elementi za transfer će postojati 
ukoliko i banka Korisnika ima ugovorene metode i pravila za prihvataanje informacija o 
plaćanju, kao i metod i pravila za prihvatanje informacija o iznosu izvršenog plaćanja. 
Na osnovu toga, banka Korisnika će koristiti primljene infonnacije da odobri račun 
Korisnika, učini sredstva dostupnim za korišćenje kada je to moguće i na kraju će 
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informisati Korisnika o izvršenom transferu sredstava na njegov račun. 

Svrha međubankarskog kliringa i poravnanja jeste da se na korektan način razmene 
informacije i na siguran način izvrši razmena vrednosti. Zahtev za servis kliringa i 
servis izvršenja izravnanja je indukovan potrebom za transfer novca između banaka. 

Prostor Credit Transfers se particioniše na: 

1. Credit Transfers Initiation - inicijacija platnog naloga; 

2. Credit Transfers Clearing and Settlement - poravnanje i izvršenje platnog 
naloga; 

3. RTGS Settlement - izvršenje naloga. 

Bruto poravnanje se ne izvršava u sistemu Credit Transfers, već u RTGS sistemu, gde 
se vrši konačno poravnanje. Sistem RTGS nije predmet analize, već je to samo 
komunikacija prema RTGS sistemima i od njih ka Credit Transfer sistemu. 




1 . 


2 . 


3. 


Slika 68. EPC Model Credit Transfers -а iz knjige pravila [98] 
Sve tri grupacije poslova se particionišu po mestu gde se odvija procesiranje: 


I Retail System: 

Odvija se kod Nalogodavca, odnosno Korisnika. Nalogodavac i Korisnik komuniciraju 
sa bankom. Zbog mesta odvijanja procesa ovaj segment se naziva „ Retail SvstenC. 


II Bank’s Retail Credit Transfer System & Processor Credit Transfers System: 

Odvija se u banci i bavi se komunikacijom banke sa svojim klijentima i prosleđivanjem 
zahteva procesorskoj kući. Zbog mesta odvijanja procesa ovaj segment se naziva 
„ Bank’s Retail Credit Transfers SvstenC prema klijentima i „ Bank’s Processor Credit 
Transfers System“ prema procesorskoj kući/kućama. 


III Processor’s Neto System & Bruto System: 

Odvija se u procesorskoj kući i bavi se komunikacijom sa bankama i RTGS sistemom 
(odnosno sistemom za izvršavanje poravnanja). Zbog mesta odvijanja procesa ovaj 
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segment se naziva „ Processor’s Neto System“ prema bankama i „ Processor’s Bruto 
System“ prema sistemu za bruto poravnanje. 

Iz gornjeg sledi da se sistem za Credit Transfers sastoji od pet osnovnih podsistema: 

1. Retail Svstem; 

2. Bank’s Retail Credit Transfers System; 

3. Bank’s Processor Credit Transfers System; 

4. Processor’s Neto System; 

5. Processor’s Bruto System. 

Podsistemi su determinisani i posmatraju se na taj način jer su distribuirani elemeti 
sistema za koje su različite: 

Kvalifikacije ( retail korisnici, banke i procesorske kuće kvalifikovane su za obavljanje 
različitih poslovnih procesa koji međusobno nemaju nikakvih zajedničkih elemenata). 

Autorizacije ( retail korisnici, banke i procesorske kuće autorizovane su od različitih 
odgovomih subjekata za različite poslove i nalaze se u jedinstvenoj poslovnoj vertikali). 

Odgovornosti (postoji jasno determinisano vlasništvo nad poslovima). 

Navedeni podsistemi Credit Transfers uklapaju se u generički model. 

Direct Debit (platni promet po osnovu direktnog zaduženja) kao lokalni instrument 
plaćanja unutar evrozone, SEPA ( Single Euro Payment Area) [71] ima za cilj da zameni 
trenutni pristup poravnanju učesnika u nacionalnim i međunarodnim okvirima čije su 
osnovne prednosti sledeće: 

• jednostavan i jeftin način za prenos sredstava; 

• mogućnost određivanja tačnog datuma za prikupljanje potrebnih sredstava; 

• pouzdanost izvršenja plaćanja u predefinisanom vremenskom ciklusu [67]; 

• šansa za optimizaciju tokova novca i upravljanjem sa sredstvima; 

• automatsko knjiženje (razduživanje) prispelih plaćanja; 

• mogućnost da se automatizuju REJECTS (odbijane pre započinjanja procesa 
naplate), REFUSALS (odbijanje zahteva pre likvidacije ili poravnanja), 
RETURNS (odbijanje zahteva posle poravnanja), REVERSALS (povraćaj ili 
stomo započete naplate zbog nedostatka sredstava na računu dužnika koji se 
konstatuje nakon kliringa), REVOCATIONS (opoziv instmkcije naplate od 
strane poverioca u skladu sa Ugovorom poverioca i njegove banke), 
REQUEST FOR CANCELATION (zahtev za otkazivanje je opoziv 
instrukcija naplate od strane banke kreditora), REFUNDS (refimdiranje 
sredstava dužniku od strane njegove banke prema ugovom); 

• jedan platni instmment u okvim SEPA za zaduživanje bankovnih računa u 
SEPA zoni; 

• mogućnost za prikupljanje sredstava korišćenjem jednog platnog 
instmmenta; 

• redukcija administrativnih troškova i povećana sigumost zbog korišćenja 
digitalnog potpisa mandata, kada elektronski potpis bude moguće koristiti. 

Formalan opis osnovnog toka procesa platnog prometa po osnovu direktnog zaduženja, 
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učesnika u ovom procesu, kao i opis formata poruka u komunikaciji između finansijskih 
institucija dati su u nastavku. 

Platni promet po osnovu direktnog zaduženja (u daljem tekstu Direktno zaduženje) 
predstavljaju transakcije koje inicira poverilac na osnovu mandata, Prilog 4, u cilju 
izmirenja međusobnih obaveza. Mandat (dokument Specifikacija mandata za obavljanje 
platnog prometa po osnovu Direktnog zaduženja) je dokument kojim dužnik daje 
ovlašćenje svom poveriocu da inicira transakcije i svojoj banci da postupa u skladu sa 
instrukcijama iz tih transakcija, a koje će rezultirati zaduženjem dužnikovog računa. 
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• Banka dužnika ( Debtor Bank ) je banka kod koje je račun dužnika. 

• Dužnik (Debtor) je pravno ili lizičko lice koje mandatom daje pomenuta 
ovlašćenja poveriocu i banci dužnika, i čiji se račun zadužuje. 

Na slici 69. prikazan je proces Direktno zaduženje - Osnovni tok: 

• PT04-01 Collect Information for Collection (prikupljanje informacija za 
zbirku): poverilac priprema podatke za instrukciju Direktnog zaduženja. 

• PT04-02 Pre-notify the Debtor (predobaveštavanje dužnika): poverilac 
obaveštava Dužnika o datumu prezentovanja instrukcije banci dužnika i iznosu 
kojim će biti zadužen. 

Vremenski okvir [ > D-14CD ]: obaveštenje se šalje najkasnije 14 
kalendarskih dana (u daljem tekstu ,,CD“) pre naznačenog dana izvršenja 
instrukcije (u daljem tekstu ,,D“). 

• PT04-02bis Initiate Refusal (iniciranje odbijanja): na osnovu obaveštenja, 
Dužnik može da naloži Banci dužnika da odbije instrukciju 

• PT04-03 Send the Collections (slanje zbirke): Poverilac šalje jednu ili više 
instrukcija Banci poverioca. Kao obavezan deo svake instrukcije, poverilac šalje 
i potrebne informacije iz Mandata. 

Vremenski okvir [D-2TD < send date < D-14CD ]: aktivnost može 
otpočeti najranije 14 CD od dana D. Aktivnost se mora završiti 
najkasnije 2 bankarska dana (u daljem tekstu ,,TD“) od dana D. 
Vremenski okvir [D-5TD< send first / one-off] : u slučaju jednokratne 
instrukcije i prve instrukcije višekratnih instrukcija, aktivnost mora 
završiti najkasnije 5 TD od dana D. 

• PT04-04 Reject some Collections (odbijanje nekih zbirki): Banka poverioca 
vraća nevalidne instrukcije poveriocu. 

• Corrections: Poverilac vrši ispravku nevalidnih instrukcija. 

• PT04-05 Send the Collections (slanje zbirki): Banka poverioca šalje 
instrukcije Klirinškoj kući. 

• PT04-06 Reject some Collections (odbijanje nekih zbirki): Klirinška kuća 
vraća nevalidne instrukcije Banci poverioca. 

• PT04-07 Send the Collections (slanje zbirki): Klirinška kuća šalje instrukcije 
Banci dužnika, koje sadrže potrebne informacije iz Mandata. 

Vremenski okvir [ D-2TD < send date < D-14CD ]: aktivnost može 
otpočeti najranije 14 CD od dana D. Aktivnost se mora završiti 
najkasnije 2 bankarska dana (u daljem tekstu ,,TD“) od dana D. 
Vremenski okvir [ D-5TD< send first / one-off ] : u slučaju jednokratne 
instrukcije i prve instrukcije višekratnih instrukcija, aktivnost mora 
završiti najkasnije 5 TD od dana D. 

• Clearing and Settlement (kliring i poravnanje): Klirinška kuća izračunava 
neto pozicije i vrši poravnanje. 

• PT04-08 Reject some Collections (odbijanje nekih zbirki): Banka dužnika, 
vraća instrukcije koje nisu validne Klirinškoj kući sa razlogom odbijanja. 

Vremenski okvir : aktivnost počinje odmah po prijemu instrukcija, a 
mora se završiti pre naznačenog dana D. 
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• PT04-09 Debit the Debtor (zaduživanje dužnika): Banka dužnika zadužuje 
račun dužnika za navedeni iznos i datum u instrukciji. 

Vremenski okvir [ D>debit>D+5TD ]: aktivnost može otpočeti najranije 
dana D, a mora se završiti do 5 TD od dana D. 

• PT04-10 Send Returned Collection (slanje odbačenih kolekcija): Ukoliko 
Banka dužnika ne može da zaduži račun Dužnika, instrukcije moraju biti 
vraćene Klirinškoj kući sa razlozima vraćanja. 

Vremenski okvir [ D>debit>D+5TD ]: aktivnost može otpočeti najranije 
dana D, a mora se završiti do 5 TD od dana D 

Pri izvršenju Direktnog zaduženja, propisano je da banka i klirinška kuća (u daljem 
tekstu Finansijske institucije) razmenjuju informacije definisane preko niza DS 
struktura (DS - Dcita Set). Svaka DS struktura predstavlja skup podataka neophodnih za 
obavljanje pojedinih aktivnosti unutar procesa Direktnog zaduženja. 

Zbog različitih aktivnosti i uloga učesnika u procesu, neki DS može imati više 
pojavljivanja u različitim fizičkim porukama. Fizičke poruke su propisane UNIFI (ISO 
20022) standardom, i one su stvami nosioci informacija u komunikaciji finansijskih 
institucija. UNIFI standard grupiše pomke u sledeće oblasti: 

• Payment Initiation (iniciranje plaćanja) predstavlja komunikaciju između 
Dužnika i Poverioca sa bankom dužnika i bankom poverioca, respektivno. 
Prefiks u oznaci pomka iz ove oblasti je ,,pain“ {pavment initiation ). Upotreba 
ovog skupa pomka nije obavezujuća, ali ga SEPA standard prepomčuje. 

• Payment Clearing and Settlement (kliring i poravnanje plaćanja) predstavlja 
komunikaciju između finansijskih institucija, i prefiks u oznaci pomka iz ove 
oblasti je ,,pacs“ (pavment clearing and settlement). Upotreba ovog skupa 
pomka je po SEPA standardu obavezujući. 

Slika 70. opisuje ugovorene relacije i interakciju između glavnih učesnika procesa 
direktnog zaduženja. Učesnici su uslovljeni sa relacijama označenim brojevima: 

(1) Ugovorene relacije pravilima sa kojima su se učesnici saglasili. 

(2) Između dužnika i poverioca postoji potreba da se izvrši plaćanje koje je 
rezultovalo potpisivanjem mandata - ugovora kojim poverilac stiče pravo 
iniciranja finansijske transakcije direktnog zaduženja u svoju korist na račun 
dužnika. 

(3) Između banke poverioca u skladu sa pravilima kojima je determinisan servis 
direktnog zaduženja realizuje se inicirana transakcija direktnog zaduženja. 

(4) Dužnik se obaveštava o budućoj transakciji i o izvršenoj transakciji po 
pravilima. 

(5) Banke dužnika izvršavaju transakciju direktnog zaduženja preko mehanizma 
sistema za poravnanje po pravilima. 
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Slika 70. Ugovorena interakcija učesnika u procesima direktnog zaduženja [98] 
Navedeni Direct Debit procesi uklapaju se u generički model dat u poglavlju 5.1.1. 
Procesi Direct Debit i Credit Transfers se uklapaju u generički model. 

5.4 Matematički model EPPS-a 

Rekurzija je već jako dobro poznat pojam iz oblasti matematike i kibernetike. U 
poslovnom okruženju rekurzija se veoma retko koristi eksplicitno [187]. Međutim, 
rekurziju je moguće primeniti u sistemima koji su kompleksni: korišćenjem slučaja gde 
je unutrašnjost sistema hijerarhijski rekurzivna (specijalan slučaj koji se pojavljuje 
veoma često u praksi, pogotovu u domenu platnih sistema), korišćenjem slučaja gde su 
objekti sistema rekurzivni i korišćenjem slučaja gde se javlja rekurzivni problem koji 
treba rešiti. Veoma često se sreću rekurzivne ruske figurice zvane ,,babuške“, a slika 71. 
sadrži još neke primere. „Objekat se naziva rekurzivnim ako on sadrži samog sebe kao 
deo ili ako je definisan sa nekim svojim delom“ [187]. 



Slika 71. Primeri rekurzivnih modela 



Slika 72. Rekurzivna struktura finansijskog tržišta u Srbiji 
{Wholesale nivo - nivo banaka, Retail nivo - nivo pravnih i fizičkih lica) 
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Sistem se, dakle, ne sastoji samo od elemenata sa atributima i relacijama između njih, 
već i od činjenice da pripada nekom nadređenim sistemu i da se sastoji od podređenih 
sistema, odnosno za svaki sistem može se pronaći struktura kojoj pripada. Na slici 72. 
prikazan je platni sistem koji ima rekurzivnu strukturu. 

Rekurzivna struktura se, sem kao odnos između skupova, može predstaviti i na nekoliko 
drugih načina. Jedan od načina je i prikaz sa ugnježdenim zagradama, pa tako struktura 
sa slike 72. može da izgleda ovako: (G(D, E(A, B, C), F)). Jasno je da se rekurzivni 
objekat može prikazati i rekurzivnom strukturom. Prikaz može da bude i tabelaran, u 
kome kolone predstavljaju hijerarhijski nivo u okviru samog rekurzivnog objekta, a 
vrste nazive elemenata koji se ponavljaju, kao što je prikazano na slici 73. 

Nivo NBS 
Wholesale nivo 


Retail nivo 


G 




D 



F 



E 




A 



B 



C 


Slika 73. Rekurzivna struktura (inansijskog tržišta 
u Srbiji, prikazana u tabelarnom obliku 

Na osnovu prethodnog razmatranja, sledi matematički model rekurzivne strukture: 

Platni sistem Srbije se sastoji od sistema za plaćanje na više nivoa. Najniži nivo je onaj 
na kome se vrši akvizicija i (inalna distribucija informacija o platnim transakcijama. To 
je Retail nivo. Nivo iznad je nivo poslovnih banaka, odnosno Wholesale nivo. Iznad 
nivoa poslovnih banaka je nivo RTGS Narodne banke Srbije [220]. Iznad nivoa RTGS 
Narodne banke Srbije nalaze se različiti nivoi globalne razmene infonnacija o platnim 
transakcijama. 

Platni sistemi iste namene na različitim nivoima po svojoj funkcionalnosti su 
ekvivalentni. Označimo na taj način dobijeni bazični model sistema na sledeći način: 

(1) BM, gde je BM bazični model sistema. 

Neka F/(k) predstavlja model sistema na k-tom nivou. Funkcija f(X) neka predstavlja 
funkciju transformacije unije više sistema koja je jednaka X. Transformacija sistema se 
ogleda u autorizovanosti nad podacima, odgovomosti i dodeljenoj potrebnoj 
kvalifikovanosti koja se sprovodi kroz propisivanje zakonske regulative, normi i 
primene dmgih propisanih standarda. Preslikavanje//je takvo da se na višim nivoima 
razlike R n .i preslikavaju u tačku (preslikavanje zanemamje R„.j na višem nivou), jer se 
radi o funkcijama sistema koje nisu predmet sistema višeg nivoa. 

Neka R\ predstavlja deo sistema višeg nivoa od onog koji ima unija sistema X a koji 
nije sadržan u uniji sistema X. 
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Pretpostavimo da se sistem na najnižem nivou može realizovati korišćenjem bazičnog 
modela, kao na slici 74: 

(2) F,(0)=f,(BM) U Ro, l e N, R 0 je ostatak sistema koji nije sadržan u BM. 



Na osnovu prethodnih razmatranja, nivo n sistema se može predstaviti na sledeći način: 


(3) F t (ri) = j\ ([J F t (и -1» , k l, m, n e N . 

k= 1 


Model opisan fonnulom (3) može se gralički prikazati kao na slici 75. 



Slika 75. Grafički prikaz modela sistema n-tog nivoa 

Primer: 

Neka su Fi(n-l), F2(n-1) i Fs(n-i) tri različita platna sistema različitih banaka, tj. sistemi 
za Credit Transfers, Direct Debit i kliring čekova, respektivno. Tada će sistem Ffn) biti 
procesorska kuća za Credit Transfers, Direct Debit i kliring čekova. Neće imati, recimo 
zakonom propisane obaveze R„p koje funkcija f preslikava u tačku (odnosno 
zanemaruje), ali će imati njoj namenjene funkcije koje se odražavaju u razlici R„. 

Kada su sistemi Ffn-l), Ff(n-1) i Ffn-I) iste vrste, recimo Direct Debit, onda se 
fonnula (3) uprošćava i nije potrebno tražiti uniju jer su sistemi na nivou n-1 
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ekvivalentni, pa je dovoljno primeniti funkciju transforamcije na bilo koji sistem i 
dodati razliku R n da bi se dobio sistem nivoa n. U ovom slučaju je i sistem n-tog nivoa 
ekvivalentan sa bilo kojim od sistema n-1 nivoa. 

5.5 Metod razvoja modela EPPS-a 

Razvojem savremenih standarda u informacionim tehnologijama i napretkom u oblasti 
komunikacionih tehnologija, automatizacija u domenu sistema elektronskog poslovanja 
platnih sistema postaje aktuelnija, a sve je izraženija tendencija u povezivanju 
segmenata poslovnih sistema, poslovnih procesa sa adekvatnim skupovima podataka u 
njima. Standard za analizu, zadavanje i implementaciju poslovnih sistema podržanih 
informacionim tehnologijama koji se opisuje u ovom radu rešava niz problema 
povezanih sa odgovomošću, autorizacijom i kvalifikovanošću različitih subjekata koje 
poslovni sistem sadrži. Na primer, jasno se razdvajaju uloga i zadaci u analizi, 
zadavanju i implementaciji tehnologa posla koji treba da se podrži sa informacionim 
tehnologijama od tehnologa sa znanjima informacionih tehnologija. Primeri su i 
zadavanje procesa od strane tehnologa posla koji se opisuje u Operativnim pravilima i 
opisivanje stmktura podataka u XML šemama od strane IT tehnologa. 

Potpisani elektronski dokumenti u jednom sistemu su na osnovu Zakona o elektronskom 
potpisu [136] i Zakona o elektronskom dokumentu [144] ravnopravni sa ostalim 
zakonski priznatim dokumentima. Mnogi standardizovani sistemi pomka sadrže i 
odgovarajuće pozicije u okvim pomka za elektronski potpis i na taj način obezbeđuju 
bezbedan prenos podataka. Detenninisanje sistema se postiže definisanjem dokumenata 
koji definišu poslovni ambijent u kome se odigravaju poslovni procesi, odnosno 
adekvatno i konzistentno poslovno okmženje, Prilog 7. Opisan je postupak 
determinisanja poslovnih sistema, koji se može primeniti na svaki sistem za obradu 
transakcija ili neki njegov deo. Sistemi za obradu transakcija su dizajnirani da 
procesiraju mtine različitih poslovnih transakcija efikasno i na strogo determinisan 
način. Svaki poslovni sistem ima potrebu za jednim ili više sistema za obradu 
transakcija, na primer: za fakturisanje, za plaćanje, za praćenje, za izračunavanje poreza, 
taksi i dmgih davanja, za preračun potrebnih materijala za proizvodnju, za kontrolu 
stanja magacina i slično. 

Ukoliko neki elementi za predloženi postupak nisu standardizovani, prepomka je da se 
pre determinisanja izvrši standardizacija elemenata potrebnih za operativna pravila, 
uputstvo o formatu i nameni pomka, tehničko uputstvo i šeme pomka. U finansijskoj 
industriji izvšena je standardizacija, tako da za isti element postoji više različitih 
standarda. Često takav odnos prema standardima nosi sa sobom mnoge teškoće, 
materijalne izdatke i dodatne rizike. 

Finansijske institucije definisanjem univerzalnih standarda pokušavaju da prevaziđu 
takvu situaciju, tako da se sada stvaraju standardi kojima ostali konvergiraju, sa 
intencijom potpune zamene sa novim standardima. Osnovni standardi za ovakav način 
determinisanja sistema možemo naći u standardima propisanim za finansijsku razmenu 
pomka, kao što su IS020022 i SWIFT. Razmenu pomka za integraciju koristi Narodna 
banka Srbije (veoma intenzivno - oko milion finansijskih transakcija dnevno) i 
Klirinška institucija banaka Udmženja banaka Srbije. Specifičnost oba sistema je 
potpuna determinisanost sa operativnim pravilima. U slučaju Narodne banke Srbije, to 
je determinisanost sa operativnim pravilima za obračun u realnom vremenu i kliringu 
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[135], kao i uputstvom o formatu i nameni poruka. Slični sistemi su opisani i u 
publikaciji o platnim sistemima izdatoj od strane Danske nacionalne banke [49], [165]. 

Dokumenti koji treba da budu produkovani da bi se sistem mogao zadati i na osnovu 
toga i implementirati predstavljeni su u Tabeli 10, gde je predstavljena i odgovomost za 
pojedinačni dokument [20]. Za izradu svakog dokumenta potrebno je sprovesti zasebnu 
analizu nekom od raspoloživih metodologija. Navedeni dokumenti predstavljaju i 
osnovne dokumente potrebne nadležnim organima za odobravanje rada sistema i 
procesa koji su na taj način zadati [14]. Navedeni dokumenati neophodan su ali i 
dovoljan uslov za započinjanje i realizaciju funkcionalne specifikacije kao prvog koraka 
implemantacije sistema [21]. Predstavljeni dokumenti su zadati industrijskim 
standardima, zakonskom regulativom, normativnim aktima i drugim raznorodnim 
standardima koje treba uzeti u obzir prilikom analize potrebne za njihovu izradu [86]. 


Rbr. 

Opis dokumenta 

Odgovomost 

Dokument 

1 . 

Operativna pravila 

Tehnolog posla 

Prilog 1. 

2. 

Format i namena poruka 

Tehnolog posla 

Prilog 2. 

3. 

Termin plan 

Tehnolog posla 

Prilog 3. 

4. 

Tehničko uputstvo 

IT tehnolog 

Prilog 5. i Prilog 6. 

5. 

Poslovna pravila 

IT tehnolog 

Prilog 5. i Prilog 6. 

6. 

Sheme 

IT tehnolog 

http://www.ubs-asb.com/ 

KIB, Direktna zaduženja računa, 
UBS platna šema 

7. 

Instance 

IT tehnolog 


Tabela 10. Vrsta dokumenata i odgovornost za izradu 

Operativnim pravilima zadaje se ponašanje sistema, uzevši u obzir standardne osobine 
koje treba da ispune. Tehničko uputstvo determiniše strukturu sistema a termin plan 
definiše periodiku procesa sistema (učestalost dešavanja). Dokument „Format i namena 
poruka“ ima zadatak da povezuje ponašanje sa strukturom, odnosno operativna pravila 
sa tehničkim uputstvom. Sheme i instance poruka su praktični artifakti koji mogu da 
služe za implementaciju konkretnih kategorija u sistemu (formi, interfejsa, struktura za 
prihvatanje konkretnih instanci sistema). 

Opis dokumenata: Svaki od dokumenata, bez obzira na prirodu sistema koji se 
determiniše i bez obzira na definisanu arhitekturu razmene poruka, sadrži 
fenomenološki analogne fakte koji se na istovetan način opisuju i zadaju u svakom od 
njih, pa su i navedeni dokumenti iste strukture koja je u nastavku i navedena. 

Operativna pravila: Naziv ovog dokumenta je „Operativna pravila za realizaciju IME 
SISTEMA“, gde je IME SISTEMA tačan naziv sistema koji se realizuje. Pored verzije 
sistema, atribut dokumenta je i datum verzije, primer u Prilogu 1. Produkcioni sistem 
mora podržati sve važeće verzije dokumenta, izuzev onih za koje je nalogodavac 
eksplicitno naznačio da se ne smeju podržavati. Operativna pravila se sastoje od: 

• osnovnih odredbi i pojmova u kojima se naznačuje na osnovu koje regulative 
sistem ima autorizaciju i odgovomost, definicija aktera u sistemu, definicija 
osnovnih entiteta sistema koji su predmet sistema, definicija osnovnih procesa 
koji su predmet sistema; 

• načina i uslova koje učesnici treba da ispune; 

• odgovomosti učesnika i mere zaštite; 
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• definicije šta predstavljaju podaci, kako se od podataka sačinjavaju poruke - 
dokumenti i način kako se ti dokumenti razmenjuju; 

• definicija prava i obaveza učesnika; 

• rokova u kojima se procesi moraju obavljati; 

• način realizacije osnovnih procesa; 

• način rešavanja izuzetaka i reklamacija; 

• definiše se način sistema obaveštavanja biroa za procesiranje o promenama 
statusa, validnosti primljenih dokumenata, odbijanju instrukcija, osnovnih 
podataka o procesiranju instrukcija, ostvarenoj realizaciji instrukcija i 
realizovanim instrukcijama, kao i odgovarajućeg skupa infonnacija o promeni 
statusa učesnika, njegovih instrukcija i odbijanju instrukcija; 

• način i uslovi isključenja učesnika iz sistema; 

• naknade za poslove biroa za procesiranje; 

• moguće dodatne servise; 

• završne odredbe koje se odnose na sam dokument, odnosno operativna pravila. 

Operativna pravila imaju prvi zadatak da povežu realni sistem sa aktuelnom zakonskom 
regulativom i standardima koji se koriste prilikom obavljanja poslovnih procesa. 
Operativna pravila zadaju i učesnike sa preduslovima za njihovo uključenje u sistem, 
uslove rada i isključenja u sistem. Operativna pravila moraju da određuju ambijent i po 
pitanju definisanja pojmova i drugih osnovnih elemenata sistema. Pored načina i uslova 
za rad učesnika, determinišu se i mere zaštite i odgovomosti, način realizacije i 
obezbeđenje obavljanja poslovnih procesa, kao i skupovi podataka koji ih obezbeđuju, 
na koji način se učesnici u sistemu obaveštavaju, način rešavanja reklamacija, terminski 
plan za obavljanje poslovnih procesa, dodatni servisi, tarife, kao i specijalne završne 
odredbe koje u nekim specijalnim aspektima determinišu sistem. 

Format i namena poruka: Naziv ovog dokumenta je „Uputstvo o nameni i fonnatu 
pomka za sistem NAZIV OSNOVNOG TEHNOLOŠKOG PROCESA“. Pored verzije 
sistema, atribut dokumenta je i datum verzije, primer u Prilogu 2. Produkcioni sistem 
mora podržati sve važeće verzije dokumenta, izuzev onih za koje je nalogodavac 
eksplicitno naznačio da se ne smeju podržavati. Uputstvo o nameni i formatu pomka 
sastoji se od: 

• osnovnih pojmova koji determinišu tehnološko okmženje u kome se odvijaju 
procesi; 

• tehnološke stmkture podataka; 

• specifikacije osnovnih procesa i procesa za rešavanje izuzetaka; 

• specifikacije procesa za rešavanje reklamacija; 

• definicije osnovnih i ostalih dokumenata - pomka; 

• definicije administratorskih pomka; 

• definicije pomka na nivou razmene dokumenata; 

• tehnološka pravila za realizaciju instmkcija; 

• tehnološka pravila za realizaciju procesiranja; 

• definicije proširenog skupa servisa. 

Uputstvo o formatu i nameni pomka određuje skupove i tokove podataka potrebnih za 
obavljanje poslovnih procesa. Definišu se registri učesnika i registri drugih objekata koji 
se u sistemu procesiraju. Procesi elektronske razmene dokumenata ovim uputstvom se 
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povezuju sa konkretnim skupovima podataka i porukama koje se detaljno opisuju u 
dokumentu „Tehničko uputstvo“. Uputstvo o fonnatu i nameni poruka, pored toga što 
opisuje namenu poruka, definiše i poslovnu upotrebu definisanog skupa poruka. 
Uputstvo određuje osnovnu komunikaciju i servise elektronske razmene dokumenata i 
procesiranje. 

Terminski plan: Naziv ovog dokumenta je „Terminski plan za sistem IME 
SISTEMA“, gde je IME SISTEMA tačan naziv sistema koji se realizuje, primer u 
Prilogu 3. Pored verzije sistema, atribut dokumenta je i datum verzije. Produkcioni 
sistem mora podržati najnoviju verziju dokumenta. Terminski plan se sastoji od 
infonnacija o radnom vremenu biroa za procesiranje, terminskog plana sa izabranim 
periodikama koje se zadaju sa sledećim atributima: opisom poslovnog procesa, 
oznakom dokumenta sa kojim se proces realizuje i terminom realizacije. 

Tehničko uputstvo: Naziv ovog dokumenta je „Tehničko uputstvo za poruke NAZIV 
OSNOVNOG TEHNOLOŠKOG PROCESA“, primer u prilozima 5 i 6. Pored verzije 
sistema, atribut dokumenta je i datum verzije. Produkcioni sistem mora podržati sve 
važeće verzije dokumenta, izuzev onih za koje je nalogodavac eksplicitno naznačio da 
se ne smeju podržavati. Tehničko uputstvo se sastoji od opisa struktura dokumenata - 
poruka sa indeksom koji jedinstveno determiniše element u poruci, kardinalnosti 
elementa, naziva elementa, tipa podataka elementa, opisa i dcfinicije poslovnih pravila 
koji se odnose na taj element. U tehničkom uputstvu se opisuje i svrha poruke, ko je 
generisao dokument, opis osnovne strukture. U tehničkom uputstvu se specificiraju i 
šifarnici ili kodovi za šifarnike. 

Tehničko uputstvo dcfi nišc detaljan format poruka sa sledećim atributima za svaku 
poziciju u okviru poruke: 

• index (jedinstveni identifikator u okviru poruke); 

• obaveznost (da li je obavezno ili opciono polje); 

• naziv pozicije u poruci (naziv XML čvora); 

• XML tag; 

• kardinalnost; 

• tip; 

• identifikator poslovnog pravila ukoliko ga ima za datu poziciju. 


2.16 EmailAddress <EmailAdr> 

Ргечепге: [0..1] 

ОеПиШоп: Addiess for elecnouic mail (e-rnail). 
Data Туре: Max256Te\t 
Fonnat: ina\Leugth: 256 
nuiiLength: I 


Slika 76. Primer opisa pozicije EmailAddress 
u IS020022 tehničkom uputstvu 

Svaka od pozicija naknadno se detaljno opisuje, kao što je to prikazano na slici 76. 
Pored navedenih elemenata, definišu se precizno i poslovna pravila sa identifikatorom 
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poslovnog pravila navedenog uz poziciju u poruci i detaljan opis sa eventualnim 
preporukama za implementaciju pravila. 

Poslovna pravila: Naziv ovog dokumenta je „Poslovna pravila za poruke NAZIV 
OSNOVNOG TEHNOLOŠKOG PROCESA“, primer u prilozima 5 i 6. Pored verzije 
sistema atribut dokumenta je i datum verzije. Produkcioni sistem mora podržati sve 
važeće verzije dokumenta, izuzev onih za koje je nalogodavac eksplicitno naznačio da 
se ne smeju podržavati. Poslovna pravila se sastoje od detaljnog opisa poslovnog pravila 
u odnosu na indeks elementa ili više indeksa elemenata na koje se poslovno pravilo 
odnosi, odnosno element poslovne poruke. 

Šeme poruka: Šeme poruka proističu iz dokumenta Tehničko uputstvo i Poslovnih 
pravila. Šeme poruka se materijalizuju u XML formatu. U sebi sadrže infonnacije o 
strukturi dokumenata i osnovnim ograničenjima nad odgovarajućim skupovima 
podataka. 

Instance poruka: Instance poruka se operativno koriste prilikom realizacije sistema i 
praktičnih provera pretpostavki tokom analize i implementacije sistema. Strukture 
podataka mogu da budu kompleksne i instance služe za provere osnovnih 
implementacionih pretpostavki. 

Navedeni opisani proces zadavanja sistema standardizuje i analizu sistema koju treba 
sprovesti u procesu implementacije informatičke podrške poslovnim procesima. 

5.5.1 Identifikacija komponenata modela EPPS-a 

Ontologija, u skladu sa najzastupljenijom defmicijom elektronskog poslovanja jeste 
„specifikacija konceptualizacije” [79], [29]. REA ( Resource-Event-Agent ) ontologijaje 
specifikacija deklarativne semantike uključene u poslovne procese [127]. Teorija koja 
stoji iza REA je iz oblasti računovodstva, gde je REA prvi put uvedena, i njene 
komponente imaju jasne mikroekonomske izvore koji su povezani specifičnim vezama i 
u mnogo slučajeva koriste se u praksi prilikom izgradnje informatičke podrške 
poslovnih sistema [17]. U UN/CEFACT radu sve definicije REA ontologije su 
primenjene u kolaborativnom prostoru između poslovnih sistema [29] gde se tržišna 
razmena obavlja u tesnoj povezanosti dva ili vise poslovnih entiteta [83]. U uprošćenoj 
varijanti, REA može biti predstavljena kao UML dijagram klasa sa asocijacijama i 
generalizacijama u odnosu na klase objekata. 

Osnovni REA model prvi put je publikovan u julu 1982. u izdanju časopisa The 
Accounting Review [84]. Osnovne premise ovog rada izdržale su sve teoretske izazove u 
narednih 20 godina i danas je zastupljen u obrazovnim, praktičnim i teoretskim 
kontekstima (ISO15944-4:2007). Slika 77. ilustruje osnovnu strukturu REA ontologije. 
Sa leva nadesno su konfigurisani ekonomski resursi, ekonomski događaji i ekonomski 
agenti i to je tipičan poslovni kolaboracioni patern i izvor imena modela REA. Uspešna 
poslovna saradnja podrazumeva pre svega dve vrste ekonomskih događanja, od kojih 
svaka opisuje ekonomske resurse koji su uključeni u razmenu između dva trgovinska 
partnera [191]. Na primer, dobavljač (Partner u trgovini) prenosi vlasništvo nad 
automobilom (ekonomskim resursom) klijentu (Partneru u trgovini) u zamenu za koji će 
(dualna asocijacija) Kupac obezbediti novac (ekonomski resurs) za dobavljača. Postoje 
dva dualne instance objekta čiji je obrazac prikazan na slici 36, gde prenos predstavlja 
pravni ili ekonomski osnov za drugu instancu. 
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R E A 



dualnost 


Slika 77. Osnovna REA ontologija [219] 


Deklarativna semantika prikazana na slici 77. je centralna za sve relacije u ekonomiji. 
Ekonomski resursi su objekti koji imaju vrednost i koji su pod kontrolom jednog od dva 
agenta. Partneri u trgovini uvek očekuju transfer resursa kada se angažuju. Dakle, slika 
77. je obrazac za svaku ekonomsku razmenu [78]. U elektronskoj trgovini stvarna faza 
razmene je dobro opisana sa objektnom strukturom prikazanom na slici 77. Međutim, 
trgovinskim partnerima u dugoročnim odnosima potrebno je više poverenja i predvidiva 
struktura poslovanja u kojima su obe strane unapred ugovorile ponašanje prilikom 
razmene. REA ontologija opisuje ovo proširenje sa dodatnim klasama [102] prikazanim 
kao ekonomska obaveza, ekonomski ugovor i sporazum, prikazani na slici 78. 


Ekonomski 

ugovor 

utvrdjuje 


rectuliše 

I I 

Sporazum 


recipročno 


Ekonomska 

obaveza 


ispunjava 



Slika 78. REA ontologija sa obavezom (angažovanjem) [219] 

Obaveza je obećanje partnera u trgovini da će inicirati ekonomski događaj. Inicirani 
ekonomski događaj će ispuniti tu obavezu [185]. Obećanja mogu biti recipročna od 
strane drugog partnera u trgovini, koji se obavezuje da će inicirati drugi tip ekonomskog 
događaja zauzvrat. Ekonomski ugovor je skup reciprotetnih obaveza između partnera u 
trgovini koji sa sobom nose jedno ili više ekonomskih razmena u budućnosti. Ugovor je 
podtip mnogo uopštenije klase objekata zvane sporazum, a sporazum može regulisati i 
drugi sporazum. U slučaju automobile-za-pare razmene biće uključena obaveza sa 
kojom se kupac mora saglasiti da prihvati isporuku automobile na određen datum, na šta 
će zauzvrat biti ugovorno obavezan da napravi seriju gotovinskih isplata dobavljaču 
automobila. Na dnu slike 78. prikazana su dva dodatna objekta. Lokacija i Izjava. 
Materijalizacija izjave je nešto što je potrebno partneru u trgovini kada se insistira na 
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dokumentima parcijalne razmene, na primer kada kupac automobil uzima u posed pre 
nego što ga je isplatio u celosti. Ovaj dodatak je više stvar uobičajenog poslovanja od 
ontološke kompletnosti. Lokacija je drugi objekat koji je ponekad potreban da bi se 
ispunio ekonomski transfer. Lokacija prosto identifikuje mesto koje zauzima ekonomski 
događaj. Ekonomske i ontološke zasnovanosti obaveza su više opisane u radovima 
Geerts-a i McCarthy-ja [83]. 

Obrasci objekata prikazani na slici 78. primami su deskriptivi u smislu ilustracije šta se 
stvamo događa u ekonomskoj razmeni ili šta se za nju obećava. Ove deskriptivne 
komponente su argumentovane iz perspektive komponenata koje dozvoljavaju 
specifikaciju kontrolnih polisa ili kolaborativnih obrazaca. Ove izvršne komponente su 
obezbeđene sa inkluzijom tipa slika osnovnih deskriptivnih objekata [7]. Dijagram klasa 
na slici 79. prikazuje ovu dopunu. Dodatni tipovi na slici 79. su naneti u dva navrata: tri 
osnovne deskriptivne klase - ekonomski agent, ekonomski događaj i ekonomski agent 
(partner) imaju klase dodate za njihove tipove; ove nove klase su povezane sa 
deskriptivnim objektima tipizirajući asocijaciju. Na primer, tip resursa može biti različit 
tip automobila; kao primer ekonomskog događaja mogu biti uzete transakcije građana 
ili transakcije finansijskih organizacija, svaka sa različitom stmkturom; a kao primer 
ekonomskog agenta (partnera) mogu biti uzete različite klase zaposlenih, svaka sa 
različitim zahtevanim tipom treninga; klasa lokacija takođe je tipizirana; primer tipa 
lokacije mogu biti različiti tipovi dokova za utovar sa različitim veličinama i različitim 
brzinama utovara. Za upotpunjavanje ekonomskog obećanja neophodna je asocijacija 
između svaka dva nova nivoa tipa objekata. Ovo je ilustrovano na slici 79. sa 
navedenim asocijacijama. 



Slika 79. REA ontologija sa tipovima [219] 

Postoje i dmge REA asocijacije koje nisu ilustrovane na slici 79. da bi se dijagram 
učinio manje kompleksnim. REA ontologija je dobro poznata i dosta se koristi u 
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knjigovodstvenom domenu a u manjem obimu i u domenu poslovnih sistema poslovanja 
preduzeća. Funkcionalni kriterijumi i REA mogućnosti primene REA ontologije 
navedeni su u tabeli 11. 


Funkcionalni 

kriterijum 

REA objašnjenje 

Da li izražava konsenzus 
znanja zajednice? 

Originalni rad i sve nadogradnje od kada je publikovan u časopisu The Accounting Review, IEEE 
Intelligent Systems, etc. i postao je otvoren za konstantna preispitivanja 1 kritiku. 1996, originalni 
rad je dobio prvu nagradu Seminal Contribution to the Accounting Information Systems Literature 
od strane American Accounting Association. Rad je kasnije ocenjen 2003 godine i od strane 
Accounting Education Award sa najvisom ocenom AAA. 

Da se koristi kao referenca 
precizno definisanih 
termnina? 

Tri vodeće knjige o analizi i dizajnu knjigovodstvenih sistema koriste REA veoma intenzivno da 
definišu primitive sistema i objasne modeliranje knjigovodstvenih pojava. 

Da li je jezik koji je 
korišćen dovoljno jasan? 

REA primitive mogu biti korišćeni da modeliraju bilo koju ekonomsku pojavu u poslovnom 
okruženju. Danas, svaka preduzimljiva logika može biti primenjena u nekom broju slučajeva ali 
samo one koje su povezane na nekom nivou granuralnosti sa REA primitivima mogu biti 
dokumento vane. 

Da li je stabilna? 

Originalni rad je publikovan 1982. godine. Nema suštinske kritike svojih funkcija koje su 
objavljene u međuvremenu do danas. 

Da li može biti krišćena za 
rešavanje različitih tipova 
problema ili kao početna 
osnova za konstrukciju 
više vrsta primene? 

REA može biti korišćen kao model i za dizajn komponenata u knjigovodstvenom softveru. 
Takođe, može biti korišćen za modeliranje drugih povezanih poslovnih procesa ili poslovnihh 
kolaboracija za ebXML ili TMWG od UN/CEFACT. Takođe, može biti korišćen za modeliranje 
intemih fenomena u poslovanju između poslovnih sistema kao što su lanci snabdevanja, ali i za 
analizu efeikasnosti softvera u okviru poslovne organizacije. Staviše, proizvedena dokumentacija 
se može izraziti na više nivoa granulamosti, u rasponu od visokih nivoa lanaca vrednosti i lanaca 
snabdevanja, pa do nivoa toka osnovnih poslovnih procesa. Originalni model pokriva i inter i intra 
transakcije među poslovnim jedinicama. 


Tabela 11. Ontološki kriterijumi i REA ntologija 
Tabela 12. prikazuje poređenje ISO Open - EDI [55], REA - Ontology i UN/CEFACT. 


Koncept 

ISO Open-EDI 

REA Ontologija 

UN/CEFACT 

Naglasak na „ekonomskoj 
vrednosti“ kao osnovi za 
poslovni proces i definiciju 
poslovne saradnje 

Poslovna transakcija 
odnosi se na razmenu 
neke od vrednosti 

Uključuje određene ekonomske 
događaje u kojima jedan privredni 
resurs (vrednost pod kontrolom 
preduzeća) razmenjuje za dmgi 
ekonomski resurs 

Poslovna saradnja je aktivnost 
u kojoj se stvara jedan objekat 
merljive vrednosti, kao 
obavljena usluga ili kao 
kreiran proizvod 

Određeni ,,glumci“ ili 
agenti koji učestvuju u 
ekonomskim aktivnostima 
unutar ili između poslovnih 
preduzeća 

Osoba je pravno ili 
fizičko lice koje ima 
sposobnost da prihvati 
obaveze i da ih ispuni, 
kao i posledice koje iz 
njih proizilaze 

Ekonomski agenti su lica i 
organizacioni delovi koji učestvuju u 
ekonomskim događajima preduzeća 

Partner je actor u poslovnoj 
kolaboraciji 

Sposobnost da se stvore i 
prenesu informacije o 
,,obavezama“ kao kritične 
komponente elektronske 
trgovine 

Ključna osobina 
poslovne transakcije je 
da uključuje obaveznu 
razmenu između osoba 

Obaveza je dogovor da se izvrši 
ekonomski događaj u dobro 
definisanoj budućnosti, koji će 
rezultirati povećanjem ili smanjenjem 
sredstava 

Obećanje je obaveza da se 
izvrši ekonomski događaj 
(prenos vlasništva nad 
određenom količinom resursa 
određenog tipa) 

Prethodno uhodani obrasci 
za različite klase 
kolaboracije elektronskog 
poslovanja 

Open-edi scenarioje 
formalna specifikacija 
klasa poslovnih 
transakcija koji imaju isti 
poslovni cilj 

Scenario je konfiguracija tipova 
događaja, vrste resursa, tipova 
obaveza, kao i agregiranih tipova 
agenata 

Deklarativno kolaboracioni 
obrasci su razvijeni na osnovu 
BRV komponenata UMM 
metamodela 


Tabela 12. Poređenje metodologija: ISO, REA i UN/CEFACT 

Poslovne transakcije su modelirane za registrovanje, referenciranje i ponovno korišćenje 
scenarija i komponenata scenarija uz korišćenje tehnika za identifikaciju ključnih 
komponenata poslovnih transakcija, odnosno poslovnih objekata. Poslovni transakcioni 
model ima tri osnovne komponente pod nazivom ^ersori" (osoba), „Process" (proces) i 
,JData ” (podaci). Ove tri fundamentalne komponente poslovnog transakcionog modela 
(Business Transaction Model - BTM) su reprezentovane grafički na slici 80. 
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Slika 80. Poslovni transakcioni model - osnovni elementi 

Koristeći UML kao fonnalnu deskriptivnu tehniku dolazimo do sledeće UML 
reprezentacije poslovnog transakcionog modela, koji je prikazan na slici 81. 



Slika 81. UML reprezentacija slike 80. 

Poslovni transakcioni model se fokusira na osnovne potrebe razmene informacija 
između učesnika sa sledećim osnovnim karakteristikama: da akcije slede jasno 
definisana pravila, da su uključene obaveze strana, da je uspostavljanje obaveza između 
osoba automatizovano, da učesnici kontrolišu i održavaju svoj status, da učesnici 
učestvuju autonomno, da mnogostruke istovremene transakcije mogu biti podržane uz 
sledeće zahteve: jasno dcfinisana dogovorena upotreba, sa eksplicitno definisanim 
jednoznačnim ciljem, ranije definisan skup aktivnosti i/ili procesa, predefinisani i 
strukturirani podaci [56], obaveze među osobama, koje se uspostavljaju kroz 
elektronsku razmenu podataka. 

Poslovni transakcioni model ima dve klase ograničenja i to: internu klasu ograničenja i 
ekstemu klasu ograničenja [47]. Ove dve klase ograničenja poslovnih transakcija su 
ilustrovane na slici 82. 
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Sektor A 

Sektor B 

Sektor C 







Eksterna ograničenja: Javna administracija 

Interna ograničenja 


Standardi 
specifični za 
sektor 



Zajednički 

međusektorski 

standardi 

(osenčeno) 



VEZE 



Pogled na funkcionalne servise 
(informaciona i telekomunikaciona infrastruktura) 


Slika 82. Poslovni transakcioni model: klase ograničenja 

Identifikacija kategorija poslovnih subjekata EPPS-a: U skladu sa definicijom pojma 
Person u platnim sistemima imamo sledeće REA agente: 

• Retail Person (osoba koja učestvuje u prometu „па malo“) 

o pravno lice; 

o fizičko lice (svako ljudsko biće koje ima zakonska prava da inicira 
plaćanje); 

• Agent plaćanja 

o Pravno lice koje ima zakonom priznate i odobrene servise za pravna, 
fizička lica i finansijske organizacije; 

• Banka 

o U skladu sa definicijom BlS-a; 

• Klirinška kuća 

o U skladu sa definicijom BlS-a; 

• Centralna banka 

o U skadu sa definicijom BlS-a. 

Identifikacija kategorija poslovnih resursa EPPS-a: U skladu sa definicijom pojma 
Resurs, u platnim sistemima imamo sledeće REA resurse: 

• roba: koja pripada trgovinskom lancu i može biti prezentovana u sistemu koji se 
naslanja na platni sistem; 

• pravo: fizičko lice sa svojim pravima nad instrumentom plaćanja, platnim 
računima i porukama za iniciranje plaćanja; 

• uslužni servis: može biti isporučen od strane platnih agenata, banaka, klirinških 
kuća i centralne banke. 
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Identifikacija kategorija poslovnih događaja EPPS-a: U skladu sa defmicijom pojma 
Event, u platnim sistemima imamo sledeće REA događaje: 

• korišćenje platne instrukcije; 

• ekstrahovanje platne instrukcije iz platnog instrumenta od strane banke; 

• ekstrahovanje platne transakcije iz platne instrukcije od strane klirinške kuće; 

• razne kalkulacije procesora, instrukcije poravnanja i slično. 

5.6 Provera validnosti poslovne transakcije EPPS-a 

Registraciono telo prilikom svakog slanja poruke i odgovora na poruku od svih učesnika 
u sistemu prima istu takvu poruku i skladišti je. Registraciono telo ima zadatak da 
arhivira poruke i potvrde prijema i na taj način za treća lica, na specijalan zahtev, na 
primer za potrebe sudskog veštačenja, učini procese elektronskog poslovanja sledljivim 
i neporecivim. Svi dokumenti su potpisani i imaju potpisane potvrde prijema od strane 
učesnika koji je poruku dobio. Primer registracionog tela u llnansijskoj industriji 
prilagođenog posebnim aktivnostima poslovnih procesa Kompanije Dunav osiguranje je 
Dunav arhiva, sistem za čuvanje poslovnih poruka i arhivističke dokumentacije. 

Arhivističke kategorije kao što su način rukovanja i izdavanja dokumenata, tip 
dokumenta, kategorija dokumenta i kategorija vreme čuvanja propisani su zakonskom 
regulativom i intemim dokumentima sistema. Jedno Registraciono telo postoji i u 
Udmženju osiguravača u Beogradu, koji je specijalizovan za izdavanje registracionih 
brojeva polisa i čuvanje dokumenata osiguravajućih dmštava u poslovima izdavanja 
polisa autoodgovomosti, odnosno obaveznog osiguranja vozila u saobraćaju. Sistem u 
Udmženju osiguravača na zahtev osiguravajućih dmštava izdaje dokumente koji su 
pohranjena u sistemu na osnovu kojih osiguravač ostvaruje popust prilikom ugovaranja 
obaveznog osiguranja vozila. 

Usluge Registracionog tela moraju da budu usklađene sa zakonskom regulativom uz 
poštovanje aspekata ekonomske efikasnosti, zaštite životne sredine i, iznad svega, 
aspekta bezbednosti. U registracionom telu svi procesi treba da se konstantno 
nadgledaju i evidentiraju od strane edukovanog osoblja. Na taj način se ustanovljava 
zatvoren bezbednosni sistem u kome se svi procesi konstantno prate. Da bi moglo da 
garantuje apsolutnu sigumost toka operacija Registraciono telo treba da vrši nadzor 
samostalno uz periodični eksterni ekspertski nadzor. 

Bezbednosni standardi, redovna obuka zaposlenih, kontinuirano praćenje procesa u 
skladu sa međunarodnim standardima, poverljivo uništavanje u skladu sa DIN 32757, 
protivprovalni sistem, kontrola pristupa, video nadzor sa digitalnim zapisom događaja, 
zaštićena baza podataka sa backup-o m, dizaster sajtom, laka pretraga dokumentacije, 
napredno indeksiranje, praćenje svih operacija, izdavanje potvrda o uništenju, 
neprestano nadgledanje i obnavljanje resursa neki su od aspekata koji moraju da se 
obezbede na pravi način. Potrebno je obezbediti praćenje svih operacija, posebno vršiti 
trace pristupa i pregleda dokumenata koje je potrebno čuvati pod posebnim uslovima. 

Neke od sekundarnih prednosti ovakvog tretiranja dokumentacije su: optimalno 
iskorišćenje prostora, smanjenje troškova, zaštite, izbegavanje troškova prostora za 
arhivu i održavanje istih, stabilnost troškova arhiviranja, predvidljivi troškovi 
arhiviranja, olakšano praćenje rokova dokumentacije. 
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5.6.1 Sistem provere podataka 

Procesi koji su dozvoljeni u okviru registracionog tela su Insert, View, Move. Proces 
Update ne postoji, pa ukoliko želi da se popravlja stanje zapisa u Registracionom telu, 
onda se prave novi zapisi koji su ravnopravni sa postojećim, i prilikom veštačenja se 
uzimaju svi zapisi ravnopravno, kao i razlog zbog kojeg je postojala potreba za 
procesom Update. Proces Delete nije dozvoljen i ukoliko želi da se popravlja stanje 
zapisa u Registracionom telu, onda se prave novi zapisi koji su ravnopravni sa 
postojećim, i prilikom veštačenja se uzimaju svi zapisi ravnopravno, kao i razlog zbog 
koga je postojala potreba za procesom Delete. 

Proces View je moguć uz posebne administrativne dozvole i ukoliko se poznaju potrebni 
elementi za pronalaženje dokumenta, odnosno ukoliko je poznat broj potvrde prijema. 
Tehnike pretraživanja i pretraživanja sekundarnih baza podataka sa izvedenim 
skupovima podataka daju veću fleksibilnost u pretrazi i mogućnost semantičkog 
povezivanja zapisa dostupnim tehnologijama. Binami zapisi se pre potpisivanja 
konvertuju u base64 format koji nije moguće pretraživati na standardan način, ali mogu 
se pretraživati sekundame baze podataka nastalih iz binarnih formi na standardan način 
i može se vršiti povezivanje sa primarnim bazama. Prilikom stvaranja sekundamih baza 
podataka mogu da se koriste i tehnike optičkog prepoznavanja, prepoznavanja govora, 
oblika i dmgih tehnika. Na taj način multimedijalne informacije mogu postati dostupne i 
mogu da se vrše povezivanja multimedijalnih artifakata sa bazama primamih 
dokumenata, i da se obogaćuju postojeće veze između dokumenata, ali i da se stvaraju 
nove, koje mogu dati nove poglede na dokumentaciju pohranjenu u Registracionom 
telu. U zdravstvu, podaci koji su neophodni za poslovne procese su multimedijalni, 
recimo, savremeni zdravstveni karton, pa je jasno i da je od posebnog interesa za 
ovakav sistem administracija sistema koja mora da zadovolji sve aspekte bezbednosti i 
zaštite sistema Registracionog tela. 

5.6.2 Sistem provere koraka poslovnih procesa 

Proces View u registracionom telu omogućava pronalaženje dokumenata, uz posebne 
administrativne dozvole i ukoliko se poznaju potrebni elementi, odnosno ukoliko je 
poznat referentni broj transakcije. Referentni broj transakcije omogućava pronalaženje 
svih instmkcija i pomka u kojima se navedena transakcija u procesu izvršenja nalazila, 
odnosno potpunu rekonstmkciju procesa kroz koji je transakcija sa traženim referentnim 
brojem prošla. 

5.7 Metode integracije platnih sistema 

U finansijskoj industriji uobičajena je razmena pomka povezanih sa izvršenjem 
finansijskih instmkcija [22]. Razmena pomka podrazumeva korišćenje uzoraka [172], 
[72] sa sledećih aspekata: tačaka sa kojih se vrši razmena pomka, sadržaja i konstmkcije 
pomke, usmeravanja poruke, transformacije pomke, izbora kanala prosleđivanja pomke, 
upravljanja sistemima razmene pomka. Svaki od navedenih aspekata podržan je sa više 
uzoraka; na primer, za transformaciju pomke poznati su sledeći uzorci: Message 
Translator, Envelope Wrapper, Content Enricher, Content Filter, Claim Check, 
Normalizer, Canonical Data Model [90]. Važno je napomenuti da su opisani uzorci 
namenjeni integraciji, a ne i dizajnu softvera. Uzorci vezani za dizajn navedenih sistema 
[231], iako od velikog značaja za ovu tematiku, nisu predmet ovog rada. 
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Sistem se mora implementirati da bi se obezbedio (saglasno dizajnu) visok nivo 
skalabilnosti, a posebno sa aspekta uvećanog obima podataka u postojećim bazama 
podataka, prenos informacija, uvećanje broja raspoloživih servisa i uvećanje broja 
korisnika servisa. Obezbeđivanje skalabilnosti ne treba uticati na održavanje traženih 
nivoa sigumosti, raspoloživosti i performansi. Povećanje poslovnog opterećenja sistema 
primamo bi mogao da bude prouzrokovano povećanjem količine infonnacija snimljenih 
u postojećim bazama podataka informatičkih sistema koje postoje u institucijama 
uključenih u sistem, povećanjem broja transakcija, povećanjem broja servisa, 
povećanjem složenosti transakcija, povećanjem kompleksnosti servisa, povećanjem 
broja korisnika (krajnjih korisnika ili dmgih sistema elektronskog poslovanja). 

Sistem mora biti implementiran na takav način da omogući povećanje kapaciteta 
procesiranja, bez promena u arhitekturi. Dizajn sistema treba da obezbedi da se 
adaptibilnost i proširivost ne desi po ceni opadanja sistemskih perfonnansi 
svakodnevnog rada. Potrebno je implementirati sledeće zahteve: dodavanje novih 
usluga, dodavanje novih tipova podataka (mogući su multimedijski i biometrijski 
podaci), dodavanje novih metaopisa, dodavanje novih korisnika i uloga, dodavanje 
novih servisa, kreiranje novih servisa koji predstavljaju kombinaciju postojećih, 
implementaciju polisa i pristup servisima, implementaciju polisa i pristup podacima 
preko korišćenja servisa. 

U dizajn sistema potrebno je ugraditi medijatorske interfejse koji treba da izvrše 
prilagođavanje fonnata podataka preko njihove konverzije u jedinu XML šemu. Uvek 
kad postoje, treba da se upotrebljavaju standardi za razmenu podataka. 

Sigurnosni, odnosno bezbednosni zahtevi interoperabilnosti definisani su u standardu 
ISO 17799 koji pokazuje sigurnost infonnatičkih sistema kao rezultat dizajniranja, 
sprovođenja, rukovođenja i kontinuiranog unapređenja. Zbog sigurnosti informacija 
moraju se primenjivati sigurnosne polise i periodično se revidirati i ažurirati u odnosu 
na rizik za narušavanje sigurnosti. Polise su defi nisanc: opisom strana involviranih u 
servisu, korisnicima, administratorima, rukovodiocima i kontrolnim telima. Uloge i 
odgovornosti strana uključenih u obezbeđivanje servisa sa aspekta primene i upravljanje 
polisama moraju biti jasno definisanc, identifikovane i periodično kontrolisane. Kao 
podrška polisama, mora se obezbediti mogućnost definisanja aplikativne podrške 
operativnim procedurama, koje prenose principe sigumosne politike u praksi (u 
različitim tehnološkim sredinama, za različite korisnike i sistemske operatore). Glavne 
operativne procedure su: procedure koje omogućavaju prikladnu zaštitu, snimanje 
zaštitnih kopija i arhiviranje dcfinisanih servisa, koji će obezbediti mogućnost za 
obnavljanje dostupnosti servisima nakon eventualnih prekida u radu; procedure za 
monitoring i kontrolu svih nivoa infrastrukture koje su povezane sa postupcima za 
vcrifikaciju i kontrolu, što omogućava otkrivanje i sleđenje preuzetih operacija pri 
korišćenju servisa; procedure za upravljanje nedozvoljenim zahtevima za korišćenje 
usluge i odgovarajuće reakcije u slučaju prestupa ili problema u sigurnosti sistema; 
procedure za autorizaciju i pristup sistemu; procedura za kreiranje, upravljanje i brisanje 
korisnika; procedura za primenu kriptografske zaštite. Jasno se mora dcfi nisati: gde, za 
koje poruke i kad treba koristiti kriptografsku zaštitu, kako se upravlja ključevima 
kriptografske zaštite, kako reagovati u slučaju problema sa zaštićenim pomkama ili pri 
gubljenju sertifikata ili ključeva za kriptografsku zaštitu, procedure za povezivanje 
prema postojećim informacionim sistemima u institucijama, postupak koji mora 
uključivati i dcfi nisanje osnovnih nivoa sigumosti, periodične provere i zaštitne mere 
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koje treba preduzeti. Servisi su predmet kontrole i moraju obezbediti način za sledljivost 
porekla i prava korisnika servisa. Pri tome treba voditi računa o regulisanju dostupnosti 
usluga spoljašnjim telima, opisu domena bezbednosti u saglasnosti sa nacionalnim i 
internim sigumosnim regulativama, polisama nacionalnog nivoa, polisama određene 
institucije i slično, klasifikacijama informacijama i odgovornosti u skladu sa evropskim 
bezbednosnim regulativama Saveta Evropske unije, o definisanju prava pristupa i 
ograničavanju pristupa podacima, definisanju bazičnog nivoa bezbednosti (politike 
poverenja), koje se primenjuje na sve strane koje komuniciraju sa sistemom za državnu 
interoperabilnost. 

Moraju se obezbediti postupci za centralnu evidenciju koji obezbeđuju periodičan 
monitoring uključujući upravljanje alarmima pri korišćenju servisa. Vazno je 
napomenuti da evidentiranje ne obuhvata same podatke, nego samo korisnike servisa, 
tip servisa i metaopisa servisa. Aktivnosti koje treba da se evidentiraju uključuju sve 
potražnje za korišćenjem servisa, sve odgovore potražnje uspešne i neuspešne, metaopis 
servisa, sve pristupe sistemu i sve izvršene događaje, kao i neuspešne ili neovlašćene 
pristupe sistemu. Centralna evidencija mora omogućiti administratorima da slede 
aktivnosti po vremenu njihovog izvršenja i da identifikuju korisnike koji su izvršili 
svaku pojedinačnu aktivnost, i po potrebi, mora pomoći u identifikaciji krajnjih 
korisnika. Zbog toga što se nijedna aktivnost ne može izvršiti ukoliko se ne može 
evidentirati, sistem evidentiranja mora uvek biti na raspolaganju i mora predvideti 
sekundami bekap podataka za evidenciju. 

Podaci sa evidencije se ne mogu modifikovati. Podaci evidencije se ne mogu brisati pre 
zakonskog datuma isticanja važnosti. Svaki korisnik mora biti u mogućnosti da pregleda 
evidenciju svih aktivnosti izvršenih sa njegove strane ili aktivnosti izvršenih na 
njegovim podacima. Možda će biti potrebno evidenciju transakcija korisnika vratiti 
korisniku pa zbog toga treba obezbediti mere za pojednostavljenja ovog zadatka. 
Evidencija se isto tako može koristiti i u statističke ciljeve. Moraju se razviti funkcije ili 
alati za izveštavanje i analizu kako bi se obezbedili izuzeci u upotrebi i obradive 
infonnacije recenzentima. 

U narednim poglavljima će biti opisana integracija i to na sledećim nivoima: 

• na nivou procesa razmene podataka u poglavlju 5.7.1; 

• na nivou pretprocesiranja u poglavlju 5.7.2; 

• na nivou procesiranja podataka u poglavlju 5.7.3; 

• na nivou postprocesiranja u poglavlju 5.7.4.; 

• na nivou registrovanja razmene u poglavlju 5.7.5. 

5.7.1 Razmena podataka 

Poslovna integracija može da se postigne i primenom posebnog aplikativnog sloja koji 
omogućava podsistemima jednog poslovnog sistema da budu u interakciji. Na taj način 
čine jedinstven sistem sa unijom skupa funkcionalnosti svih integrisanih sistema. Danas 
je situacija takva da su neke aplikacije u poslovnim sistemima razvijene samostalno, 
dok ostale mogu biti nabavljene od različitih nezavisnih proizvođača. Takvi aplikativni 
sistemi često rade na različitim računarskim sistema, na raznovrsnim platformama, a 
mogu biti i geografski distribuirani. 
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Aplikativni sistemi mogu da budu nekad korišćeni od strane poslovnih partnera ili 
klijenata, odnosno integrisani sa njihovim sistemima [90]. Često aplikativni sistemi 
moraju da budu integrisani iako nisu dizajnirani sa namerom da rade u interakciji sa 
drugim sistemima i ne mogu iz raznih razloga da budu menjani. 


№ 

NAZIV 

OPIS 

1 . 

PRENOŠENJE 

DATOTEKA 

Standarizovana, stmkturirana datoteka može biti nosilac potrebnih 
skupova informacija između dva sistema i na taj način može biti 
integracioni faktor sistema. 

2. 

DELJENJE BAZE 
PODATAKA 

Aplikativni sistemi mogu da se integrišu putem iste, deljene baze 
podataka, deleći iste podatke koji su uskladišteni u bazi. 

3. 

POZIVANJE UDALJENE 
PROCEDURE 

Integracija može da se izvrši i tako što jedan aplikativni sistem izloži 
odgovarajući skup procedura i dozvoli drugom sistemu da ih sa 
odgovarajućim inicijalnim podacima poziva i inicira ili izazove 
odgovarajuće ponašanje ili prostu razmenu podataka. 

4. 

RAZMENA PORUKA 

Poruka koja se sastoji od zaglavlja i tela koje nosi infonnacije potrebne 
ishodišnom sistemu daje mogućnost integracije putem posebno 
razvijanih sistema za razmenu poruka. 


Tabela 13. Načini integracije 

Integrisane aplikacije bi trebalo da minimiziraju svoju zavisnost jedne od drugih, tako 
da svaka može da se nezavisno razvija bez izazivanja dodatnih problema za ostale. 
Interfejs za integraciju aplikacija treba da sprovede zadate funkcionalnosti, ali i da bude 
dovoljno uopšten da se prilagodi promeni kada je to potrebno. Integraciju je poželjno 
izvesti na način da procesi u sistemima mogu da se odvijaju asinhrono. Ukoliko se 
izvrši projektovanje i organizacija sistema tako da procesi budu asinhroni, izvršiće se 
bez čekanja oni za koje su ispunjeni uslovi za pokretanje i na taj će se način smanjiti 
značajan utrošak vremena i ostalih resursa, koji je prisutan u nekom tačno određenom 
sinhronom scenariju. 

Postoji više pristupa integraciji aplikativnih sistema od kojih svaki ima svoje dobre i 
loše strane. Integracija se u suštini sastoji od razmene određenih, unapred definisanih 
klasa podataka i eventualnog iniciranja određenog ponašanja u zavisnosti od sadržaja 
podataka. Tabela 13. daje pregled osnovnih načina integracije koji se danas koriste. 

U svakom konkretnom slučaju integracije potrebno je izabrati najadekvatniji način jer 
nijedan od navedenih nije univerzalno najbolji niti najelegantniji. 

Integracija prenosom datoteka: Fajlovi su univerzalno skladište podataka koje svi 
aplikativni sistemi mogu da koriste uz pomoć odgovarajućih exstraktora i loadera, kao 
što je to ilustrovano na slici 83. Aplikativni sistemi proizvode i učitavaju fajlove ili u 
odgovarajućim intervalima ili aktivirani nekim događajem, u skladu sa prirodom 
procesa. Pri tome je i transformacija fajlova u različite formate vrlo često neophodna 
iako je standardizacija na globalnom nivou dostigla zavidan nivo. 
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Slika 83. Prenos datoteka 
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Prilikom razmene fajlova, potrebno je rešiti probleme imenovanja fajlova, istovremenog 
pokušaja čitanja i upisa podataka od različitih sistema, odlučivanja kada fajl više nije 
aktuelan i kada ga treba obrisati, prenosa fajlova sa jedne strukture foldera na drugi, 
prenosa fajlova sa jednog sistema na drugi ukoliko su sistemi udaljeni. 

U poslednje vreme mnoge organizacije za standardizaciju u raznim oblastima ljudskog 
delovanja koriste XML u izgradnji savremenih standarda. Postoje i mnoge kompanije 
koje se bave isključivo proizvodnjom komponenata za učitavanje, ekstrahovanje i 
transformaciju podataka. Takođe, na tržištu softverskih alata možemo pronaći vrlo lako 
pregršt alata koji mogu da se koriste za profesionalnu namenu čija je kompleksnost za 
korišćenje skoro na nivou office aplikacija. 

Integracija deljenom bazom: Ukoliko aplikacije koriste isti sistem za upravljanje 
bazama podataka, postoji mogućnost da aplikacije budu u interakciji zahvaljujući 
deljenoj bazi podataka, i na taj način budu integrisane, kao što je to prikazano na slici 
84. Ukoliko se jedna klasa svih integrisanih aplikacija oslanja na istu bazu podataka, 
onda možemo biti prilično sigumi da se oni mogu uvek koristiti dosledno, što nam 
garantuju mehanizmi baza podataka. Mogućnost determinisanja transakcija, 
zaključavanje slogova i mogućnost ažuriranja podataka iz različitih izvora daju potrebne 
elemente za upravljanje integracijom sistema. 


Sisteml j | Sistem 2 
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Slika 84. Deljenje baze podataka 

Sama integracija, implementacija komponenata, korekcije u sistemu i slične operacije 
[125] obavljaju se brzo i na standardan način od strane administratora baza podataka. 
Postoje mnogi dostupni alati koji još više olakšavaju navedene operacije. Važno je 
napomenuti i jednu nepovoljnu činjenicu za ovu vrstu integracije, a to je da je veoma 
teško implementirati unificiranu bazu podataka koja bi zadovoljila određen broj 
različitih sistema, pogotovu zbog mogućih sukobljenih potreba različitih sistema, kao 
što je brzina pristupa podacima potrebna jednom sistemu i složenost modela podataka 
koji je potreban drugom sistemu. Isto tako, u slučaju integracije deljenom bazom 
podataka, Često mogu nastati problemi koji su u vezi sa vlasništvom nad podacima, te 
se ovaj način integracije ne bi mogao preporučiti sistemima koji imaju suprotstavljene 
interese u odnosu na iste ili slične klase podataka. 

Integracija pozivom procedura: Izmena podataka može da bude prosta, da se izvrši 
promena vrednosti jednog ili više atributa. Međutim, veoma često izmena jednog ili više 
atributa može biti kompleksna operacija: promena prezimena može da pokrene i niz 
drugih procesa koji mogu da se odvijaju sekvencijalno ili paralelno. Udaljeni poziv 
procedure poseduje interfejs iza koga mogu biti sakriveni podaci i procedure koji su 
pokrenuti. Identifikacioni broj osobe i novo prezime mogu biti potrebni podaci koji 
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pokreću udaljenu proceduru, koja inicira sve odgovarajuće izmene i sve akcije koje je 
potrebno preduzeti u tom slučaju. U slučaju udaljenog poziva procedure potrebno je da 
jedan sistem obezbedi interfejse i da dozvoli njihovo korišćenje drugim aplikativnim 
sistemima, kao što je prikazano na slici 85. 
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Slika 85. Integracija udaljenim pozivom procedure 

Bitna činjenica je da svaki aplikativni sistem može da održava integritet svojih 
podataka. Isto ako, svaki sistem održava i skup svojih interfejsa, a nepovoljna činjenica 
je da za jednu istu strukturu podataka može da postoji veći broj različitih interfejsa za 
različite korisnike aplikativnih sistema. Svaka izmena jednog sistema sa velikom 
verovatnoćom povlači i moguće izmene u interfejsima koji se izlažu dugim sistemima i 
na taj način se smanjuje nezavisan razvoj različitih na ovaj način integrisanih sistema. 

Bus je podsistem koji se koristi za transfer podataka između aplikativnih komponenata u 
jednom računarskom sistemu ili između aplikativnih komponenata različitih računarskih 
sistema. 

Razmena poruka korišćenjem Message Bus- a vrši se na pouzdan način uz pomoć 
različitih i prilagodljivih formata poruka, kao što je prikazano na slici 86. Prenos može 
biti i asinhron i to je rešenje u situaciji kada distribuirani sistemi nisu u mogućnosti da 
budu dostupni. 



Slika 86. Sistem za razmenu poruka 

Enterprise Service Bus (ESB) predstavlja okruženje sačinjeno da unapredi sofisticiranu 
povezanost između servisa. Ono ustanovljava međusloj za pretprocesiranje koje pomaže 
da se prevaziđe određen skup problema povezanih sa pouzdanošću, skalabilnošću i 
nejednakošću po pitanju komunikacionih mogućnosti. ESB je sačinjen od niza uzoraka 
kao što su: asinhroni red čekanja, posrednik servisa (transformacija modela podataka, 
transfonnacija formata podataka, premošćavanje protokola), rutiranje, pouzdan prenos 
poruka, centralizacija polisa, centralizacija pravila i prenos poruka iniciranih 
događajima [69]. 
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5.7.1.1 Komunikacija zasnovana na porukama 

Poruke koje se razmenjuju u savremenim sistemima različitih namena tretiraju se kao 
dokumenti i to u elektronskoj fonni. Da bi poruke (dokumenti) mogle da se razmenjuju 
na zakonski i infonnatički konzistentan način za potrebe projekata platnog sistema bilo 
je potrebno definisati dokument, klase dokumenata, fonnu dokumenata i način 
pojavljivanja [158]. 

Definicija dokumenta: 

a) Dokument izdaje autorizovano, odgovomo i kvalifikovano lice; 

b) Sadržaj dokumenta služi za provem verodostojnosti prezentovanih infonnacija 
i/ili stvaranje novog dokumenta; 

c) Svaki dokument sadrži infonnacije uz pomoć kojih je moguće utvrditi njegovu 
verodostojnost. 

d) Dokument opisan sa a.), b.) i c.) može biti izdat i u elektronskom formatu. 

Klase dokumenata: 

• Zakonski dokument (dokument kojim nadležni organ odobrava, propisuje, 
verihkuje i kvantihkuje predmet zakonske regulative; 

• Dokument standarda (potreban je za determinisanje tehnoloških sistema); 

• Tehnološki dokument (potreban za interakciju tehnologa sa tehnološkim 
procesom u svrhu obavljanja tehnoloških procesa, odlučivanja i upravljanja 
sistemom). 

Forma dokumenta: 

• Papirna forma (priređena mčno, mašinski ili mešovito); 

• Fonna priređena IT resursom (može biti kao stmkturiran izveštaj koji koristi kao 
izvor stmkturirane podatke - recimo iz baze podataka ili kao nestmkturiran 
izveštaj jer sadrži tehnološko znanje o sistemu - recimo HELP aplikacije; 

• forma priređena kao bilo koji vid publikacije; 

• usmena izjava kao dokument (samo ako je osoba koja usmeno izgovara sadržaj 
odgovoma, kvalihkovana i autorizovana). 

Način pojavljivanja dokumenta: 

• kao osnova za novi poslovni proces tehnološkog sistema; 

• kao interakcija sa poslovnim procesom; 

• kao posledica tehnološkog procesa. 

Tokom svog životnog ciklusa dokument prolazi kroz sve pojavnosti dokumenta. Javlja 
se kao posledica tehnološkog procesa (npr. u Ministarstvu unutrašnjih poslova), u 
interakciji je sa poslovnim procesom (npr. prilikom legitimisanja pri ulasku u saveznu 
ustanovu) i kao osnova za poslovni proces otvaranja tekućeg računa (utvrđivanje 
identiteta budućeg vlasnika tekućeg računa). Sistemi bazirani na standardima dehnisani 
su oko jednog ili više objekata, ,,nosilaca“ standarda. U slučaju standardizovanih 
hnansijskih pomka, osnovni objekti su instmkcije potrebne za obavljanje hnansijskih 
transakcija. Za svaki objekat moraju da se opišu operacije kreiranja, čitanja, izmene i 
brisanja ( create, read, update i delete). Ove operacije se predstavljaju odgovarajućim 
pomkama. Da bi sistem bio konzistentan, mora postojati način da se pristupi objektima 
sistema uz pomoć pomka, te mora postojati poruka za postavljanje upita, kao i pomka 
za prosleđivanje odgovora. Primalac informacija bi u tim sistemima trebalo da ima 
mogućnost da prihvati prijem, odnosno odgovornost nad pomkom sa odgovorom ACK 
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(<acknowledge ), ili da odbije prijem, odnosno da ima mogućnst da saopšti da ne želi da 
prihvati odgovomost nad porukom sa odgovorom NAK ( negative acknowledge), bilo iz 
pravno formalnog ili iz organizacionog aspekta. Objekti nad kojima sistemi nemaju 
ingerenciju opisuju se atributima koji se nalaze u šifarnicima sistema. 

Prilikom standardizacije nekog sistema, ili proučavanja već standardizovanog sistema, 
potrebno je prvo uočiti osnovne objekte sistema i pomke koji se odnose na njih. 
Procesiranje pomka na ishodišnoj lokaciji, odnosno obrada informacija iz tako 
standardizovanih pomka, svodi se na prostu primenu skupa potrebnih operacija nad tim 
podacima. [17] 

5.7.1.2 Poruka 

Poruka je, uopšteno govoreći, objekatzakomunikaciju. Ona obezbeđuje informaciju, a, 
takođe, sama može da bude informacija. Dakle, njeno značenje je zavisno od konteksta 
u kome se pojavljuje - koristi [158]. Termin „poruka” može da se primeni i na 
infonnaciju i formu. 

Tranzijent je kratkoživuća oscilacija u sistemu prouzrokovana iznenadnom promenom 
kontinualnih parametara u sistema; softverski objekat sa kratkim i ograničenim životnim 
vekom koji se ne čuva za kasnije ponovno korišćenje. 

Perzistentnost određuje karakteristiku podataka koji nadživljavaju izvršenje programa 
koji ih je kreirao: koji je primenjen u praksi smeštanjem podataka u skladište kao što je 
file sistem ili relaciona baza podataka ili objektna baza podataka. Bez ove osobine, 
strukture podataka postoje samo u memoriji i biće izgubljene nakon prestanka rada 
programa. Perzistentnost omogućava da program bude restartovan i ponovo učitan sa 
strukturom podataka iz prošlog poziva programa. Patemi za dizajniranje koji rešavaju 
ovaj problem su container based persistence, component based persistence i Data 
Access Object model [174]. 

5.7.1.3 Sistemi bazirani na porukama - Message Oriented System (MOS) 

Remote Procedure Call ili skraćeno RPC i Data Object ili skraćeno DO su proširili 
uobičajene ( single-process ) modele programiranja na distribuirano okruženje. Oni su 
učinili komunikaciju transparentnom ili implicitnom. Message Oriented Middleware ili 
skraćeno MOM uveo je novi model za programiranje distribuiranih aplikacija baziranih 
na eksplicitnoj komunikaciji, koja može da bude transijent ili perzistent [174]. Slika 87. 
prikazuje model MOM-a, tj. primer generalne organizacije komunikacionog sistema u 
kome su hostovi povezani kroz mrežu. Dva aplikativna sistema na slici 87. povezani su 
preko komunikacionih servera i mreže. Da bi aplikativni sistem mogao da komunicira 
preko komunikacione infrastrukture prikazane na slici, mora da poseduje interfejs za 
poruke, preko koga vrši slanje i primanje poruka. Komunikacioni server, u lokalu, 
prihvata poruku i uz pomoć programa za rutiranje vrši odgovarajuće ,,pakovanje“ 
poruke i sa takvim porukama puni lokalni bafer koji je nezavisan od komunikacionih 
kanala. Iz bafera, odgovarajućim komunikacionim mehanizmima, poruka se prosleđuje 
na naznačenu adresu preko definisane mreže. Komunikacioni server, na koji je 
adresirana poruka, prima poruku i skladišti je u odgovarajući bafer. Poruka u baferu je 
od tog trenutka nezavisna od komunikacije i preko programa za rutiranje prosleđuje se 
odgovarajućem lokalnom aplikativnom sistemu. 
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Slika 87. Model Message Orijented Middleware-a 

5.7.1.4 Perzistentnost i sinhronost 

Sistem može biti i takav da primalac i pošiljalac ne moraju u isto vreme da budu prisutni 
na komunikacionoj magistrali. Ta vrsta komunikacije naziva se perzistentna. To je 
osobina koja se koristi kod Fire and Forget mehanizama za slanje poruke, gde 
pošiljalac poruke pošalje poruku i u sledećem trenutku „zaboravi” da je poslao, odnosno 
sistem pošiljaoca nakon slanja više ne vodi računa o poruci koju je poslao. Primer 
perzistentne komunikacije je prikazan na slici 88. Poštar donosi poštu koja je ubačena u 
ulični poštanski sandučić i nakon predaje pošiljke u poštanski bafer na svom ishodištu 
sigurno ne prati šta se događa sa pošiljkom nakon predaje. 



da bude poslata na odredište 
kada su poštari dostupni 

Slika 88. Perzistentni model 

Različiti komunikacioni modeli mogu da budu upotrebljeni u nekom sistemu. Izbor 
zavisi od dosta parametara, ali svi su vezani u krajnjoj instanci organizacijom posla koji 
se obavlja sadržajem poruke, mogućnošću izbora komunikacionog kanala i zahtevom da 
li na poruku u „istoj ruci” mora da se nađe prijemnica poruke ili ACK poruka, odnosno 
odbijenica poruke NAK poruka. Na slikama 89, 90. i 91. prikazani modeli su sa 
različitim osobinama u odnosu na stalnost prisustva učesnika u komunikaciji i 
sinhronizaciju potvrde prijema. 

Slika 89. prikazuje perzistentnost i sinhronost u komunikaciji: 

a. Perzistentna asinhrona komunikacija 

b. Prezistentna sinhrona komunikacija 
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Slika 89. Perzistentnost i sinhronost u komunikaciji 
Slika 90. prikazuje tranzijentnost i sinhronost u komunikaciji: 


c. Tranzij entna asinhrona komunikacij a 

d. Tranzijentna sinhrona komunikacija bazirana na potvrdi 
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Slika 90. Tranzijentnost i sinhronost u komunikaciji 


Slika 91. prikazuje tranzijentnu sinhronu komunikaciju baziranu na isporuci poruke i 
potvrdi: 


e. Tranzijentna sinhrona komunikacija bazirana na isporuci poruke 

f. Tranzijentna sinhrona komunikacija bazirana na potvrdi poruke 
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Slika 91. Tranzijentna sinhrona komunikacija bazirana na isporuci i potvrdi 


5.7.1.5 Redovi za čekanje 

Redovi za čekanje svojom paradigmom omogućavaju perzistentnost. Postoje četiri 
kombinacije za slabo povezanu komunikaciju koja koristi redove za čekanje i ona je 
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ujedno model redova za čekanje, koji su prikazani na slici 92. Primer modela reda za 
čekanje poruka koji svakodnevno koristimo je e-Mail. 


Slika 93. je generalna arhitektura redova za čekanje poruka sa vezom između 
adresiranja redova za čekanje i mrežnog adresiranja. I primalac i pošiljalac imaju svoju 
internu adresu, odnosno adresu na nivou reda za čekanje sa kojom komunicira logički 


aplikativni nivo. 
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Slika 92. Model redova za čekanje 


Na nivou reda za čekanje vrši se translacija tih adresa i mapiranje na adrese 
transportnog nivoa. Na taj način pošiljalac i primalac mogu komunicirati po modelu 
redova za čekanje prikazanom na slici 92. Sistem redova za čekanje može biti obogaćen 
i sa ruterima poruka tako da adresiranje ne mora da bude direktno. 
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Slika 93. Uopštena arhitektura modela redova za čekanje 

Nad sistemom redova za čekanje mogu da se izgrade složene sistemske aplikativne 
organizacije u cilju veće automatizacije poslovnih procesa. Slika 94. opisuje jednu 
takvu organizaciju - broker poruka, nad sistemom redova za čekanje. Broker poruka 
može adaptirati format poruke pre isporuke i ta osobina se na značajan način može 
iskoristiti u optimizaciji izgradnje sistema. U širem smislu, broker može sadržati čitav 
niz pretprocesiranja i postprocesiranja poruka. 
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baza sa pravilima 

klijent pošiljalac brokerporuka konverzije klijent primalac 



mreža 


Slika 94. Broker poruka 

Iz prethodno navedenih činjenica, nakon sagledavanja potreba sistema jedne oblasti, 
može se na kvalitetan način determinisati standardan sistem za transport. Takav 
transport je moguće izgraditi, recimo, za sistem llnansijskc industrije, i on će bez 
potrebe dograđivanja moći da pokrije ukupne potrebe za transportom svih vrsta poruka 
u oblasti llnansijskc industrije. 

Jedan takav je SWIFTNet sistem koji predstavlja podskup nad gorenavedenim 
osobinama komunikacionog kanala. Microsoft je u svom Windows Foundation - 
Communication Foundation FX sistemu (beta poznata pod imenom INDIGO) bio 
najavio mnogo jače želje - da napravi komunikacioni okvir za sve poslove koji će se 
baziraju na razmeni poruka. Svoj sistem je ugradio u Windows Framework koji sada 
može da podrži proizvoljan proces message brokera. 

Drugi pristup problematici transporta poruka korišćenjem prednosti redova za čekanje je 
Advanced Message Queue Protokol [4], specifikacija po kojoj niz nezavisnih 
proizvođača softvera već isporučuje upotrebljive open source projekte. U radnoj grupi 
za specifikacije učestvuju JPMorgan Chase & Co., Cisco Systems, Inc., Envoy 
Technologies Inc., iMatix Corporation, IONA Technologies, Red Hat, Inc., TWIST 
Process Innovations Ltd, and West, Inc. Na taj način je obezbeđen nesmetan razvoj 
specifikacije samih proizvoda kao i kritična baza korisnika tog protokola. 

5.7.1.6 Uzorci za integraciju organizacija - Enterprise Integration Patterns (EIA) 

Ovaj rad prikazuje i mogući pristup problematici razmene dokumenata u poslovnim 
sistemima korišćenjem uzorka Document Message i način postavljanja adekvatnog 
okruženja oko ovog uzorka: determinisanje poslovnih sistema operativnim pravilima, 
tehničkim i tehnološkim uputstvima, kao i tehničkim pravilima o fonnatu i nameni 
poruka. Opisan je način na koji se vrši razmena poruka, integracija raznorodnih 
poslovnih sistema prenosom podataka putem poruka kao osnovnog sredstva i Enterpise 
Service Bus kao najviši nivo organizacije opšte namene na bazi Document Mesage 
uzorka. 

Do rezultata prikazanih u ovom radu došlo se korišćenjem primera iz bankarske prakse. 
Bankarski sistemi su dobro uređeni, u njima su procesi definisani i uređeni u skladu sa 
zakonskom regulativom koja je u slučaju banaka i drugih llnansijskih institucija 
brižljivije propisana zbog same prirode poslova koji su im povereni. Zbog toga, sve 
pozitivne i negativne pojave su izraženije u bankarskim sistemima i na bazi toga mogu 
se lakše uočavati i proučavati zakonitosti u sistemima uopšte. Jedan od dokumenata 
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platnog prometa u Srbiji je Nalog za uplatu (pored Naloga za isplatu, Naloga za naplatu 
i Naloga za prenos [128]). Prilikom uplata na šalterima П nansijskih organizacija od 
popunjenog obrasca, po završetku procesa plaćanja, generišu se dva ravnopravna 
dokumenta - po jedan za svaku stranu. Isti proces se može obaviti i korišćenjem 
infonnatičkih resursa, elektronskim putem. 

Upravo ta ekvivalentnost rezultata procesa obavljenog na šalteru banke ili procesa 
obavljenog samo putem korišćenja elektronskih informatičkih resursa jeste osnova na 
kojoj se baziraju osnovne pretpostavke date u ovom radu. Dokument možemo opisati na 
sledeći način: 

• Dokument izdaje autorizovano, odgovomo i kvalifikovano lice. 

• Sadržaj dokumenta služi za provem verodostojnosti prezentovanih infonnacija 
i/ili stvaranje novog dokumenta. 

• Svaki dokument sadrži informacije uz pomoć kojih je moguće utvrditi njegovu 
verodostojnost. 

U poslovnim procesima dokument se može javiti: 

• kao osnova za novi poslovni proces tehnološkog sistema; 

• u interakciji poslovnih procesa; 

• kao posledica tehnološkog procesa. 

Na ovaj način opisan dokument može biti izdat i u elektronskom fonnatu i predstavlja 
dobm osnovu za konzistentnu integraciju poslovnih procesa. Elektronski dokumenti se 
danas ne čuvaju na posebnoj lokaciji od strane zakonom propisane posebne institucije 
kao što je to propisano zakonskom regulativom za određene vrste papirnih dokumenata. 

5.7.1.7 Postupak integracije sistema baziranog na document message uzorku 

Uzorak Document Message [90], ilustrovan na slici 95, koristi se za pouzdanu razmenu 
podataka između aplikativnih sistema. Document Message uzorak prosleđuje originalne 
podatke i omogućava primaocu pomke da se odluči šta će da radi sa primljenim 
podacima. Podaci mogu da budu poslati kao količina podataka potrebnih da opišu 
pojedinačni objekat, ali i stmktum podataka koja može da se dekomponuje u manje 
jedinice. Najvažniji deo Document Message uzorka je sadržaj pomke - dokument. 



Slika 95. Document Message uzorak 

U Srbiji je 2004. godine objavljen „Zakon o elektronskom potpisu“ koji uređuje 
upotrebu elektronskog potpisa u pravnim poslovima i dmgim pravnim radnjama, 
poslovanju, kao i prava, obaveze i odgovornosti u vezi sa elektronskim sertifikatima. 
Sadržaj dokumenta, kao i identitet entiteta koji je kreirao dokument čuva se 
potpisivanjem dokumenta. Elektronskim potpisivanjem dokumenta otklanja se 
mogućnost lažiranja identiteta, modifikovanja dokumenta i poricanja potpisa. Ukoliko 
se dokument šifruje, nije moguć ni neovlašćen pristup sadržaju dokumenta. 
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Uspešno prenošenje dokumenta od pošiljaoca do primaoca i vreme kada je dokument 
poslat veoma su bitni. Međutim, sam prijem može da bude i odložen, u skladu sa 
mogućnostima komunikacionih resursa primaoca. Garantovana isporuka je još jedan 
važan aspekt u razmeni podataka Document Message uzorkom. Važan aspekt, u odnosu 
na mogućnost prijema je i vreme važenja dokumenta, jer nakon određenog vremena 
može i da istekne važnost poslatog dokumenta i poslovni proces koji treba da se obavi 
sa takvim dokumentom ne bi bio validan. Isto tako, u komunikaciji jedan na jedan, 
važno je da se prilikom prenosa podataka ne pravi duplikat dokumenata, već se uvek 
radi samo sa jednim uzorkom - originalom. Document Message uzorkom može da se 
prenosi bilo koja poruka iz zadatog sistema poruka. Java Message Service (JMS) API 
[160], [181] je standard za razmenu poruka koji omogućava aplikativnim 

komponentama baziranim na Java Enterprise Edition platformi da kreiraju, šalju, 
primaju i čitaju poruke, sa omogućenom distribuiranom komunikacijom u kojoj 
dokument može biti serijalizovani objekat ili objekat sa tekstualnim ili XML sadržajem. 

Prilikom upotrebe Document Message uzorka dokument se obično šalje koristeći point- 
to-point kanal, za prenos dokumenata iz jednog procesa ka drugom procesu bez 
pravljenja duplikata poruke. Iz prethodnog sledi da je uzorak Dokument Message 
valjano polazište oko koga se može izgraditi konzistentan sistem [162]. 

5.7.2 Pretprocesiranje podataka 

Problem pretprocesiranja se svodi na uvođenje novih poruka u sistem. Problem 
uvođenja novih poruka u sistem i njihovo pretprocesiranje u sistemu može da se delom 
automatizuje i da se na taj način dogovori životni ciklus elemenata sistema: uvođenje 
novih funkcionalnosti u sistem, izmena starih fu nk cionalnosti uvođenjem verzija 
poruka, ukidanje funkcionalnosti ukidanjem odgovarajućih poruka u sistemu, slika 96. 

Nadređeni sistem šalje XML instancu, odnosno poruku sa sadržajem podređenom 
sistemu. Sistem primaoca poruke proverava da li je dobijeni fajl XML instanca, da li je 
verzija šeme po kojoj je kreirana instanca poznata sistemu i vrši ostale potrebne provere, 
kao na primer, da li je instanca od poznatog učesnika, da li je dobar potpis i slično. 
Ukoliko je već registrovana, odobrena i implementirana šema, odnosno verzija šeme, 
XML instanca se učitava u bazu podataka i izvršavaju se nad njom zadate operacije. 
Ukoliko nije, traži se u instanci po kojoj je šemi kreirana instanca. Sema sa zadatim 
imenom u instanci, pronalazi se na zadatoj lokaciji, koja je takođe navedena u instanci i 
odatle se preuzima. 

Na osnovu preuzete šeme generišu se upozorenje Administratoru sistema da je stigla 
instanca koja nije podržana u sistemu. Administrator, na osnovu dokumenata o 
uvođenju nove šeme: 

• daje nalog za generisanje baze (aplikacija - pogled na bazu sa pristiglim 
xsd šemama koje nisu odobrene - samo jedno pojavljivanje šeme sa 
istim nazivom); 

• daje nalog za generisanje baze iz XML šeme; 

• po kreiranju šeme daje nalog za kreiranje *.dll-a, odnosno dinamičke 
biblioteke, za učitavanje instanci u kreiranu šemu baze podataka (alat 
ima mogućnost da za generisanu bazu sam pronađe podrazumevano - 
default mapiranje); 
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• administrator određuje gde će takva instanca da se učitava 
(podrazumevanu - default šemu za tu instancu) - u aplikaciji ima 
informaciju da je generisana baza i *.dll, odnosno dinamička biblioteka; 

• odobrava da se učitavaju instance te šeme; 

• učitava sve postojeće instance šeme u bazu za pretprocesiranje; 

• šalje nadređenom sistemu poruku da je izvršeno uspešno prihvatanje 
nove instance za pretprocesiranje. 


Kreiraj .dll- 



Nadređeni sistem 

пг 


XML 

XML 

XSD 

XSD 

_L_ 


Skladište pravila 

(Shema Store) 

1 


XML 

XML 

XSD 

XSD 

_ 

_1_ 

Podređeni sistem 


Dodavanje' 

operacija 


Administrator 

podređenog 

sistema 


Odobrenje 
korišćenja 
novog — 
tipa poruke 


Slika 96. Uvođenje novih funkcionalnosti u sistem 

Instance koje pristižu preko sistema za razmenu u ovom trenutku sve mogu da se 
prihvataju na pretprocesiranje. Nakon toga, na osnovu dokumenta o uvođenju nove 
šeme, Administrator dodaje odgovarajuće operacije za prihvatanje instance iz sistema za 
pretprocesiranje u sistem za procesiranje i odgovarajuće operacije za prihvatanje 
instance za procesiranje, i šalje nadređenom sistemu poruku da je izvršeno uspešno 
prihvatanje nove instance za procesiranje. Spremište za procesiranje i operacije moraju 
da budu predefinisani po dokumentima koje je nadređeni sistem prosledio podređenom 
sistemu u procesu uvođenja nove zakonske regulative, novih normativa, pravila i slično. 
Na ovaj način se omogućava i da proizvoljan broj verzija jedne vrste poruka bude u 
opticaju, što zavisi od učesnika koji zadaje pravila u sistemu. 

5.7.3 Procesiranje podataka 

Poslovna poruka, delinisana jednim od standarda (SWIFT MT, IS020022, EANCOM 
ili bilo kojim drugim), sadrži informacije u skladu sa standardom i odgovarajućom 
regulativom (zakonskom regulativom, regulativom procesora i drugim pravno 
normativnim regulativama) koje se odnose na poslovnu oblast za koju se poruka koristi. 
Poruka u sebi sadrži jednu ili više poslovnih instrukcija, a instrukcija u sebi sadrži jednu 
ili više transakcija. Prilikom izdvajanja instrukcija iz poruke, ili prilikom izdvajanja 
transakcija iz instrukcije, po nekim strogo utvrđenim pravilima, mogu se vršiti 
transfonnacije izvornih informacija zbog potreba poslovnih procesa, odnosno 
proizvoditi derivati instrukcija/transakcija. Procesiranje je bilo koji skup operacija nad 
instrukcijom/transakcijom ili nad derivatima instrukcije/transakcije. Na primer, 
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poslovna poruka plaćanja sadrži skup instrukcija i transakcija. Obrada poruke plaćanje 
je bilo koji set operacija nad platnom instrukcijom/platnom transakcijom ili nad 
derivatima platne instrukcije/platne transakcije. 

Primeri operacija nad tako definisanim platnim instrukcijama/platnim transakcijama 
mogu biti: ekstrahovanje platne instrukcije iz platnog instrumenta, ekstrahovanje platne 
transakcije iz platne instrukcije, izračunavanje sume skupa platnih transakcija, 
oduzimanje vrednosti platne transakcije od neke druge vrednosti (na primer, sume 
drugih transakcija), odbijanje platnog instrumenta zbog neispunjavanja zadatih uslova u 
sistemu (na primer, učesnik koji formira instrukciju je blokiran), odbijanje izvršenja 
platne transakcije jer nije ispunjen zadati uslov u sistemu (na primer, ukupan iznos 
sredstava na računu neadekvatan) i slično. Na sličan način, možemo delinisati druge 
tipove procesiranja, odnosno procesiranje instrukcija/transakcija u drugim poslovnim 
oblastima. 

Način procesiranja poslovnih poruka definiše se tehnološkim procesom obrade poruka. 
Tehnološki proces definišu učesnici prema potrebama poslovnog procesa koji podržava, 
karakteristikama standarda poruka i operativnim pravilima. Jedan od načina za 
tehnološku obradu poruka u klirinškim kućama, ili procesiranje, na primeru iz mašinske 
industrije [17] navedenje utabeli 14. 


rbr. 

Proces 

Opis 

1 . 

Pribavljanje i provera 
administrativnih privilegija za 
pristup ulaznim podacima 

Sistem za procesiranje proverava da li ima raspoloživog 
materijala za procesiranje. Ukoliko utvrdi da ima, proverava 
da li ima pravo da ga koristi i da je raspoloživ za procesiranje. 

2. 

Skladištenje ulaznih 
informacija 

Ulazni podaci se preuzimaju, daje im se odgovarajući kontekst 
i vrši skladištenje. 

3. 

Procesiranje poslovnih poruka 

UML 

3.1. 

Operacijal 

3.2. 

Operacija 2 

(pisana telmologija za primenu tehnološkog procesa obrade) 

З.п. 

Operacija n 

4. 

Skladištenje izlaznih 
informacija 

Nakon procesa obrade iz konteksta informacija vrši se izbor 
načina na koji će izlazne informacije da se skladište. 

5. 

Davanje administrativnih 
privilegija za pristup izlaznim 
podacima 

Nakon skladištenja da bi bili dostupni drugim procesima, 
podacima se dodaju administrativne privilegije za pristup. 
Uobičajeno je da se grupama podataka dodeljuje odgovarajući 
status. 


Tabela 14. Proces prerade (procesiranja) poruka 

Procesiranje poruka mogu obavljati učesnici u distribuiranom informacionom sistemu 
samostalno, ali se iz praktičnih razloga pojavljuju i specijalizovane institucije, tzv. biroi 
za transport i procesiranje poruka, odnosno klirinške kuće. Oni učestvuju u samom 
poslovnom procesu koji se realizuje (npr. lancu snabdevanja), a njihov je jedini zadatak 
da vrše uslužnu obradu poslovnih poruka. 

Klirinške kuće najčešće vrše obradu poruka više različitih poslovnih procesa. Klirinška 
kuća koja bi, recimo, podržavala procese platnog sistema za međubankarska poravnanja 
po nekom standardu i procese lanca snabdevanja po EANCOM standardu vršila bi tri 
vrste procesiranja: 
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• procesiranje poruka za naručivanje, isporuku i fakturisanje poruka po EANCOM 
standardu; 

• procesiranje EANCOM poruka za Retail plaćanja; 

• sistem za Wholesale ili međubankarska poravnanja; ti sistemi su međusobno 
jasno razgraničeni, ali mogu i međusobno komunicirati jasno definisanim 
standardnim porukama. 

Cilj biroa je da vrši procesiranje raznorodnih poruka različitih standarda i povezivanje 
raznorodnih poslovnih procesa, odnosno da izvršava primenu zadatih standarda. Postoje 
različiti sistemi standardizovanih poruka za razmenu informacija u poslovnim 
procesima (inansijskc industrije, zdravstva, trgovine, carine. Kao logično pitanje, 
nameće se informatička organizacija poslovanja čiji bi predmet bila primena, 
elektronska razmena i procesiranje organizovanih podataka adekvatnim sistemima 
poruka. Danas u svetu je trend opisivanje poslovnih podataka uz pomoć proširivog 
jezika za opisivanje, odnosno XML-a. Na taj način se vrši segmentiranje poslovnih 
procesa na različite sisteme kojima pripada odgovarajući skup njihovih poruka. Svaki 
od navedenih sistema mora da bude u interakciji sa mnogim drugim sistemima putem 
kanala koji im obezbeđuje sigurnu razmenu podataka. Svi nabrojani sistemi imaju i 
potrebu da budu globalno povezani i da konekcija bude prema više raznorodnih sistema. 
Raznorodnost se ogleda i u različitosti informatičke tehnologije, ali i sa delatnošću koja 
je predmet sistema. Pregled sistema poruka prikazan u radu jeste osnova za buduća 
razmišljanja o elektronskom servisnom sistemu za razmenu podataka između 
raznorodnih institucija. Svi nabrojani sistemi doprinose poboljšanju poslovnih procesa, 
a samim tim imaju pozitivan privredni i sociološki efekat, u smislu pojeftinjenja usluga, 
smanjivanja vremena potrebnog za obradu informacija i uvođenja novih vrsta 
savremenih servisa. Navedenim prednostima se poboljšava kvalitet poslovanja javnih 
servisa i pravnih lica, a kvalitet života lizičkih lica. 

5.7.4 Postprocesiranje podataka 

Postprocesiranje ima zadatak da na osnovu standarda koji važi za sistem kome treba 
poslati poruku sastavi poruku na osnovu rezultata od potrebnih transakcija koje 
instrukcija treba da sadrži, od potrebnih instrukcija koje poruka treba da sadrži i da 
pripremi poruku za slanje. Poruka se predaje sistemu za transport poruka koji isporučuje 
poruku i vraća kao rezultat ACK, odnosno potvrdu prijema ili NAK, odnosno odbijanje 
prihvatanja poruke. ACK i NAK sadrže, pored referentnog broja transakcije, i 
jedinstvenu identifikaciju prijema/odbijanja na osnovu kog može da se pravi 
reklamacija, a u poruci ukoliko je u pitanju NAK mora da se nalazi i poruka o razlogu 
odbijanja originalne poruke. 

5.7.5 Provere putem Registracionog tela 

Putem registracionog tela u svakom trenutku administrator sistema može poslati upit u 
registraciono telo. Postoje dva slučaja: potrebne su informacije o originalnoj poruci i o 
procesu u elektronskom poslovanju platnih sistema koji je izazvala inicijalna 
transakcija. Ukoliko su potrebne informacije o originalnoj poruci, registracionom telu se 
šalje identifikacija poruke. Na osnovu identifikacije poruke dobija se originalna poruka i 
odgovarajući odgovor: potvrdu prijema ili obaveštenje o odbijanju. Ukoliko je potrebno 
da se dobije infonnacija o poslovnoj transakciji, registracionom telu se šalje upit sa 
referentnim brojem transakcije koja inicira poslovnu transakciju. Kao odgovor dobija se 
skup svih poruka koje sadrže dati referentni broj transakcije, skup svih potvrda prijema 
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ili obaveštenja o odbijanju sa vrednostima koje opisuju vremenski raspored toka 
transakcija poslovnog procesa. Provera se izvršava iz dva razloga: utvrđivanja originala 
poruke, odnosno instrukcije, odnosno transakcije i utvrđivanja toka procesa. Provera se 
može obaviti zbog internih potreba pošiljaoca poruke, ali i zbog veštačenja poruke ili 
poslovnog toka. 

5.8 Struktura predloženog modela 

Fonnat Imansijskc poruke je takav da poruke u sebi sadrže informacije koje su potrebne 
za sam prenos poruke sa jedne na drugu lokaciju, kao i tehnološke informacije - 
podatke poslovnog procesa kome su namenjene. One predstavljaju podlogu za kreiranje 
logičkog objektno orijentisanog sistema, gde su objekti u interakciji isključivo uz 
pomoć poruka [19]. 

Odabirom odgovarajućih poruka iz propisanog skupa poruka možemo da „pokrijemo” 
finansijsku celinu, tj. odabrani podskup standarda koji određuje odgovarajuću logičku 
celinu [166]. Sledi da su svi logički delovi, u stvari, determinisani normativima vlasnika 
procesa, a u skladu sa dozvolama - odobrenjima - ugovorima koje on ima u svojoj 
sredini (ambijentu) u odnosu na ostale učesnike. 

Fizički sistemi su uvek posledica organizacije vlasnika procesa [164] i oni su 
organizaciono opredeljeni ukoliko vlasnik ima pravo na osnivanje takvog vida 
organizacije, ili neke druge, a vidljivo je da su neki organizaciono opredeljeni da 
funkcionišu po finansijskoj vertikali ili geopolitički [163]. 
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Slika 97. Šema za izbor sistema za realizaciju 


Slobodan Babić \ Fakidtet organizacionih папка 


198 



















































Doktorska disertacija: Model interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama 


Na slici 97. prikazani su i drugi standardni sistemi poruka za različite namene, drugačije 
od onih koje se upotrebljavaju u platnim sistemima. To pokazuje, na još jedan način, da 
se i drugi sistemi bazirani na porukama mogu realizovati po ugledu na platne sisteme. 

Javna i privatna komunikaciona infrastruktura, bezbedonosni mehanizmi, operativni 
sistemi, sistemski softver uključujući i baze podataka, hardverski proizvodi, aktivne 
mrežne komponente, i interakcija sa okruženjem jesu segmenti koji čine ambijentalne 
uslove za rad. 

5.8.1 Globalni standardi poruka 

Može se slobodno reći da je čitav sistem determinisan odabranim sistemom poruka 
kojim se zadaju setovi podataka uz pomoć kojih se determinišu poslovni procesi. Već 
samim obimom poruka i načinom na koji se koriste određeni su mogući poslovi u 
sistemu, kao i tačan način na koji se koriste podaci, ali i setovi potrebnih podataka. Na 
taj način se do krajnosti determiniše sistem i isključuje bilo koji stepen proizvoljnosti. 
Standard IS020022 je baziran na XML standardu, preuzeo je sve dobre osobine svog 
prethodnika, a uveo sve savremene trendove u informacionim i finansijskim 
tehnologijama. Na taj način ponudio je mogućnosti koje su bile uobičajene za prethodne 
standarde, ali i mogućnost da se sa odgovarajućim tranzicionim šemama ostali 
finansijski standardi preslikaju ili dopune i na taj način približe IS020022 standardu sa 
planom konvergencije do potpunog preklapanja sa njim. 

Organizacija TWIST je izabrala Retail segment kao predmet svog delovanja, ali sa 
svojim porukama standard dozvoljava mogućnost pakovanja višenamenskog sadržaja 
koji se ogleda u mogućnosti kombinovanja poruka za plaćanja sa porukama lanca 
snabdevanja na različite načine. Setom poruka TWIST organizacije moguća je izgradnja 
uskospecijalizovanih procesorkih kuća, kao i procesorskih kuća koje objedinjuju u sebi 
više različitih poslovnih kategorija. Na taj način one daju dobar model konsolidovanja 
disparatnih poslovnih procesa i objedinjavanja na logičan način. 

Proprietarv standardi su oni koji su nastali silom prilika i predstavljaju dobru osnovu za 
sagledavanje potreba za uvođenjem novih standarda iz različitih oblasti. Jedan od 
primera koji bi mogao u budućnosti da bude odlučujući u komponovanju bankarskih 
poslovnih sistema jeste izgradnja sistema poruka koji bi podržao core procese banke. 
Na osnovu tog proprietarv standarda, uopštavanjem, može da se izgradi core banking 
standard koji bi standardizovao procese banke i na taj način razvoj core sistema banke 
učinio logičnim, jeftinijim i pouzdanijim. 

Na slici 97. u koloni za standarde nalazi se više grubo opisanih standarda koje možemo 
da odaberemo kao polazište u izgradnji platnog sistema različitih namena. Ono što se 
može predvideti jeste da će budući vlasnik platnog sistema u većini slučajeva izabrati 
jedan osnovni standard, a na osnovu geopolitičkih, ekonomskih, tradicionalnih i drugih 
činjenca izabrati ostale preovlađujuće standarde za neki geografski region sa kojima će 
sistem raditi. 

5.8.2 Logičke celine nad srodnim grupama poruka 

Svaki od standarda navedenih na slici 97. ima mogućnost da pokrije većinu poslovnih 
procesa platnih sistema. To su: Credit Transfers, RTGS, Direct Debit, Card 
Framework, eBusiness, elnvoicing, Check Clearing i drugi. Nastali su u različitim 
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sredinama iz različitih pobuda i zadaju porukama različite formate. Međutim, pošto im 
je domen nad kojim su formirani isti, uglavnom su sa istim nivoom informacija u sebi. 
Tako na primer, ukoliko se razmatra poruka, platni nalog, atributi plaćanja su u svim 
regijama sveta isti i količina informacija o platnom nalogu po svakom standardu je ista. 
Korišćenje jednog standarda u određenoj regiji uglavnom je implicirano željom za 
monopolom na tržištu transakcija, a postoji i objektivan razlog da se ne napušta 
ustoličeni standard jer su trenutna ulaganja u implementaciju novog standarda suviše 
velika, a vrlo je česta situacija da implementacija postojećeg standarda toliko košta i 
objedinjuje tolike resurse da ne postoji društvenopolitička volja da se izvrši njegovo 
osavremenjavanje. Međutim, analizom se uvek utvrđuje da su svi razlozi za opstanak 
starih standarda poruka loši i preovladava činjenica da su novi standardi veoma pogodni 
u svim fazama životnog ciklusa platnog sistema i da sa sobom nose mnoge dodatne 
prednosti. 

5.8.3 Finansijske institucije 

Finansijske institucije kroz koje je prožeta struktura platnih sistema mogu da se pode na 
dva segmenta: na veliko ( Wholesale ) i na malo ( Retail ). U Wholesale grupi su 
nacionalne banke, klirinške kuće, agenti plaćanja i banke, kao i druge finansijske 
organizacije. Retail segmentu pripadaju sve ostale organizacije (pravna lica) i fizička 
lica. Veoma je bitna činjenica da je domen platnih sistema nad oba segmenta i da je 
prilikom komponovanja platnih sistema potrebno analizirati čitavu celinu iako se razvija 
samo neki njen deo. Razlog za to je što se akvizicija podataka o transakcijama vrši u 
Retail segmentu, pa se procesiranje nastavlja sve do realizacije u delu platnog sistema 
koji pripada nacionalnoj banci. 

Finansijske institucije u odnosu na svoje nadležnosti mogu da izaberu jednu ili više 
logičkih celina nad srodnim grupama poruka za procesiranje u odnosu na jedan ili više 
standarda za poruke. Tako na primer Udruženje banaka Srbije (fizički sistem - 
institucija) nakon uvođenja Direct Debit -а imaće dva standarda po kojima radi za 
format poruka (ISO15022 i IS020022), a procesiraće platne naloge, odnosno Credit 
Transfers (u funkciji realizacije čekova) i naplatu putem direktnog zaduženja, odnosno 
Direct Debit. 

5.8.4 Transportna infrastruktura 

Message broker je program koji vrši translaciju poruke za primaoca sa fonnalnog 
protokola pošiljaoca u telekomunikacionoj mreži gde programi komuniciraju razmenom 
formalno definisanih poruka. Primeri brokera koji imaju i dodatne funkcionalnosti, 
pored opisanih u prethodnom poglavlju, jesu: Apache ActiveMQ, Comverse Message 
Broker (Comverse Technologv), eSCL Message Broker (Interface & Control Svstems), 
Financial Fusion Message Broker (Svbase), JBoss Messaging (JBoss), Microsoft 
BizTalk Server (Microsoft), Oracle Message Broker (Oracle Corporation), Proteus i 
open source implementacija od Info-Scapea, IVebSphere Message Broker (IBM), 
Cloverleaf (E-novation Lifeline). Svaki od prethodnih proizvoda, sem mogućnosti 
komunikacije i mogućnosti korišćenja za transport poruka, ima specifične 
fu nk cionalnosti koje ga opredeljuju na određeni segment funkcionalnosti. SAGA SEP 
transportna komponenta i OpenAMQ sistem, koji su opisani u prethodnim poglavljima, 
nemaju funkcionalnosti koje su povezane sa nekom drugom oblašću koja nije transport 
poruka. Oni su usko specijalizovani i njihova specijalizacija na funkcionalnost 
transporta i onih funkcionalnosti koje su striktno povezane za transport poruka čine ih 
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visokoupotrebljivim u MOS. Njihova uska specijalizovanost pomaže i u jasnom 
razgraničavanju drugih procesa platnih sistema i njihovoj informatički urednoj 
implementaciji. 

Za razliku od message brokera, Message-oriented middleware obuhvata kategoriju 
softvera za komunikaciju između aplikacija koji uopšteno počiva na asinhronoj 
komunikaciji nasuprot request/response metodi. Mnogi message-oriented middleware 
(MOM) sistemi zavise od redova za čekanje, mnogi počivaju na broadcast ili na 
multicast načinu komunikacije. Osnovna prednost ovih sistema ili protokola leži u 
mogućnostima da uskladište poruke, rutiraju ili transfonnišu u procesu dostave. 

Sistemi za transport poruka su definisani na logičkom nivou, nad protokolima 
komunikacije, tako da ne zavise od infrastrukture komunikacionih kompanija. Zbog 
njihove ekstremne fleksibilnosti i mogućnosti, kao i specijalizovanosti na 
funkcionalnosti, koje ne zavise od oblasti poslovanja na koju se poruke odnose, 
najozbiljniji su kandidat da postanu standard u svom domenu. U prilog tome ide i 
činjenica da je intencija svih globalnih organizacija za standardizaciju da se 
standardizuju poruke po domenima čovekovog delovanja, pa će tako u svim značajnim 
sistemima takav način razmene informacija biti preovladavajući. Činjenica da je po 
pitanju primene novih tehnologija message oriented paradigma dobila svoju potvrdu baš 
u domenu razvoja platnih sistema, čini da su platni sistemi postali jedna od 
najdinamičnijih oblasti. 

5.9 Model evaluacije rešenja 

Proces evaluacije rada celokupnog sistema za elektronsko poslovanje platnih sistema 
odvija se prema šemi prikazanoj na slici 98. [25] 



Slika 98. Proces evaluacije sistema elektronskog poslovanja platnih sistema 

Jedan od najvažnijih segmenata procesa evaluacije je izbor kriterijuma po kojima će se 
evaluacija vršiti. Kriterijumi koji se koriste za evaluaciju podeljeni su u tri grupe: 

• tehničko-tehnološki kriterijumi; 

• poslovni kriterijumi; 

• korisnički kriterijumi 

Liste kriterijuma za evaluaciju elektronskog poslovanja platnih sistema prikazane su u 
tabelama 15, 16 i 17. 
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Kriterijum 

Definicija 

Dimenzije 

Mere 

Interoperabilnost 

U kojoj meri su sistemi u stanju da komuniciraju 
jedni sa drugima. 


Stepen korišćenja standardnih ili 
standardizovanih formata 
podataka zasnovanih na XML-u. 

Modulama 

kompozitnost 

Korišćenje softverskih komponenata (kreiranje 
mogućnosti za ponovnu upotrebu i deljenje). 


Stepen do koje mere su pokrivene 
funkcionalnosti sistema od strane 
komponenata. 

Pouzdanost 

Obim u kome se može očekivati da sistem obavlja 
svoju fimkciju. 

Funkcionalnost 

Broj prekida rada 

Dostupnost 

Vreme u kome je sistem spreman da obavlja 
zahtevane funkcionalnosti. 

Vreme 

Procenat u odnosu na prekide u 
radu 

Bezbednost 

Koliko je u sistem moguće ubaciti neautorizovanih 
pomka. 

Broj pokušaja 

Broj uspelih pokušaja 

Performantnost 

Obim u kome se može očekivati izvršenje 
određenog broja transakcija. 

Broj transakcija i 
vreme 

Broj fmansijskih transakcija na 
sat 


Tabela 15. Tehnološki kriterijumi za evaluaciju elektronskog poslovanja platnih sistema 


Kriterijum 

Definicija 

Dimenzije 

Mere 

Stabilnost servisa 

Stabilno u dužem vremenskom okvim 

Vreme 

Broj izmena sistema u 
vremenskom okvim 

Nezavisnost 

Nezavisnost od domena primenom izolovane 
aplikativne logike 

Nezavisnost od 
domena 

Broj različitih primena 

Izolacija aplikativne 
logike 

Količina direktno implementirane 
logike 

Proširivost 

Lako za dodavanje, modifikaciju, zamenu, 
uvećanje, izmenu ili pripajanje 
funkcionalnosti 

Obimnost 

Cena izmena 

Primenljivost 

Funkcionalnost i cena primene. 

Broj primena 

Cena u odnosu na broj 
aplikativnih primena 

Količina potrebnih 
resursa za primenu 

Ukupna cena resursa za primenu 

Skalabilnost 

Lako za skaliranje 

Obinmost 

Broj transakcija 

Ekonomičnost 

Troškovi razvoja i održavanja niski i 
raspoređeni kroz vreme 

Cena 

Cena u vremenskom periodu, 

Prilog 8. 


Tabela 16. Poslovni kriterijumi za evaluaciju elektronskog poslovanja platnih sistema 


Kriterijum 

Definicija 

Dimenzije 

Mere 



Akvizivija 

Pomke se šalju onim redom kojim se kreiraju 
(da/ne) 

Sekvencijalnost 

Mogu se postizati samo u sledu. 

Distribucija 

Pomke se prihvataju onim redom kojim se 
šalju (da/ne) 

Pretprocesiranj e 

Pomke se pretprocesiraju onim redom kojim 
se primaju (da/ne) 



Procesiranje 

Pomke se procesiraju onim redom kojim se 
pretprocesiraju (da/ne) 



Autorizovanost 

Pomka koja je prihvaćena pravilno je 
potpisana (da/ne) 

Originalnost 

Prihvatljivo je samo originalno. 

Kvalifikovanost 

Pomka koja je prihvaćena neizmenjena je 
(da/ne) 



Odgovomost 

Pomka koja je stigla zabeležena je bez obzira 
da li je ispravna (da/ne) 


Prihvatljivo je obraditi prosečni 
dnevni obim u jedinici mere 
manjoj od dana. 

Transport 

Moguće je procesirati šestostmki dnevni obim 
u toku jednog sata (da/ne) 

Kapacitivnost 

Akvizicija 

Moguće je procesirati dnevni obim u toku 
jednog sata (da/ne) 


Distribucija 

Moguće je procesirati trostmki dnevni obim u 
toku jednog sata (da/ne) 

Sledljivost 

Registraciono telo zadovoljava 
kriterijum prijema, obrade i 
slanja svih zahteva - kao da se 
za svaku promenu (poruku ili 
transakciju) zahteva i 
odgovarajući izveštaj i o pomci 
i o transakciji. 

Pristupačnost 

Moguće je dobiti odgovor na sve zahteve o 
svim pomkama i transakcijama (da/ne) 

Jednostavnost 

Jasno i lako za upotrebu. 

Upotreba 

Jednostavnost u upotrebi 


Tabela 17. Korisnički kriterijumi za evaluaciju elektronskog poslovanja platnih sistema 
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6 Primena i implementacija interoperabilng EPPS modela 

6.1 Arhitektura predloženog sistema 

Postoji mnogo nivoa perspektiva saradnje (kolaboracije), na primer Centralna banka kao 
odgovoran, autorizovan i kvaliiikovan učesnik čini svoj kolaboracioni prostor. Drugi 
nivo kolaboracionog prostora poslovne saradnje je prostor lokalnih banaka koji čine 
sistem elektronskog poslovanja platnih sistema bez konekcije sa drugim centralnim 
bankama, prikazanim na slici 99. 



Slika 99. Primeri kolaboracionih perspektiva različitih 
nivoa u elektronskom poslovanju platnih sistema 

U finansijskoj industriji je veoma uočljivo da su svi učesnici povezani sa jednim super 
učesnikom koji koordinira ostale [165]. Sistemi u (inansijskim organizacijama su strogo 
hijerarhijski definisani bez šuma i lakše je uočiti hijerarhijsku zavisnost jer se radi o 
izuzetno značajnom aspektu, finansijama, od kojih sve počinje i sve se završava [27]. 
Takav je slučaj i u ostalim sistemima, ali mnogo manje uočljivo, a negde i sama 
zakonska regulativa nije tako dobro definisana kao u slučaju finansijske industrije. 

Drugi pogled je prikazan na slici 100. Slika pokazuje topologiju i dekompoziciju 
sistema i može se pokazati analizom i matematičkim modelom da su segmenti u svim 
sistemima ekvivalentni, da su segmenti koji se odnose na osnovnu delatnost jednaki, a 
da se razlikuju samo oni koji se odnose na poverene poslove, odnosno samo na one 
segmente za koje je sistem ekskluzivno odgovoran, autorizovan i kvalifikovan. Na slici 
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100. prikazan je jedan takav sistem banaka od kojih svaka kao podsistem mora da ima 
na svom nivou kao standardne komponente validator sintakse, semantike i validator 
poslovnih pravila, ali i sve ostale koji spadaju u osnovnu delatnost banke, kao i ostale 
sisteme koji podržavaju poslovne procese banke. 



Slika 100. Drugačiji pogled na sistem 

To pokazuje kako se može realizovati, na primer, osnovni set standardnih elemenata 
platnog sistema i to u RTGS centru, bankama i kod klijenata. Slika 101. prikazuje 
osnovni konglomerat - gradivnu jedinicu, a slika 102. prikazuje kako se od njega 
sačinjava platni sistem. 


procesor | 

| LOADER 1 EKSTRAKTOR 

TRANSPORTNI SISTEM 

Slika 101. Osnovni sklop standardnih elemenata RTGS sistema 



Slika 102. Grupisanje konglomerata gradivnih jedinica po nivoima 
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Navedena realizacija platnog sistema nije karakteristična samo za platne sisteme. I ostali 
Message Oriented Svstems (MOS) [10] imaju iste fenomenološke elemente: 

• postoji potreba za velikim obimom razmene poruka; 

• postoji struktura podređenih i nadređenih sistema sa super sistemom; 

• postoje veze sa drugim MOS; 

• akvizicija poruka se vrši sa veoma širokog geografskog područja; 

• distribucija poruka se vrši na veoma široko geografsko područje; 

• akvizicija i distribucija se vrše kroz zadate nivoe odgovornosti; 

• poruke za razmenu informacija o poslu su standardizovane od strane institucija 
za globalnu standardizaciju; 

• poruke za razmenu informacija sadrže informacije za adresiranje i procesiranje; 

• standardi poruka su bazirani na XML-u; 

• osnovni sklop standardnih elemenata je kao i za platne sisteme, slika 101; 

• grupisanje gradivnih jedinica se vrši kao i za platne sisteme, slika 102; 

• sisteme međusobno samo razlikuju zadati formati, infonnacije za procesiranje i 
komponente za konkretno izvršavanje procesiranja. 

Na osnovu prethodno navedenog i činjenice da je rasprostranjenost MOS u savremenom 
društvu veoma velika, od sistema za platni promet, pa do sistema za SMS mobilnu 
naplatu parkiranja u velikim gradovima priloženi radni model sistema pokazuje da je 
moguće izgraditi savremen i moderan sistem koji bi zadovoljio sve potrebne zahteve. 
Tabela 18. prikazuje komparativne prednosti razvoja softvera framework-o m u odnosu 
na uobičajeni razvoj softvera, kao i ideal kome se teži prilikom razvoja softvera. Na 
osnovu prethodnog sledi da se razvojem prihvaćene strukture i arhitekture realnog 
sistema, opisane u prethodnom i ovom paragrafu, možemo približiti idealnim 
osobinama IT sistema u funkciji podrške poslovnim procesima. 


Uobičajeni razvoj softvera 

Razvoj framework-a 

Ideal 

Specifično za aplikaciju 

Specifično za domen 

Nezavisno od domena 

Ima kratak životni ciklus 

Produžen životni ciklus za 2-3 puta 

Stabilno u dužem vremenskom okviru 

Teško za održavanje 

funkcionalnosti 

Teško za dodavanje, modifikaciju, 
zamenu, uvećanje, izmenu ili 

pripajanje funkcionalnosti 

Lako za dodavanje, modifikaciju, 
zamenu, uvećanje, izmenu ili pripajanje 
funkcionalnosti 

Proizvod je samo jedna 
aplikativna primena 

Proizvod je nekoliko specifičnih 
aplikativnih primena iz jednog domena 

Proizvod je neograničen broj 

aplikativnih primena 

Nije skalabilno 

Ograničene mogućnosti skalabilnosti 

Lako za skaliranje u mnogo smerova 

Visoki troškovi razvoja 

Visoki troškovi razvoja 

Troškovi razvoja niski i raspoređeni 
kroz vreme 

Ne može da se prilagođava 

Može da bude prilagodljivo 

Prilagodljivo 

Nema integracije 

Dozvoljava ograničenu integraciju 

Neograničena integracija 

Nije proširivo 

Ograničeno proširivo 

Neograničeno proširivo 

Ograničene mogućnosti 

Proračunate mogućosti 

Neograničene mogućnosti 

Zahteva rnnogo resursa 

Zahteva ograničene resurse 

Zahteva manje zahtevne resurse 

Nema izolovane aplikativne 
logike 

Ograničena izolacija aplikativne logike 

Kompletna izolacija aplikativne logike 

Visoki troškovi održavanja 

Razumni troškovi održavanja 

Minimalni troškovi održavanja 

Nije stabilno 

Nije stabilno 

Stabilno 

Koncentriše se na aplikativnu 
logiku 

Koncentriše se na grupu aplikativne 
logike 

Sastoji se od osnovnih znanja, 
mogućnosti da ispuni njihove ciljeve, 
vođeno neograničenom aplikativnom 
logikom 

Bez konfiguracije i 

rekonfiguracije 

Ograničena konfiguracija i 

rekonfiguracija 

Neograničena konfiguracija i 

rekonfiguracija 


Tabela 18. Neke razlike između načina razvoja softvera 
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Integracija platnih sistema putem poruka korišćenjem odgovarajućih protokola je 
bezbedna, pouzdana, i u potpunosti zadovoljava potrebe takvih sistema. Dugi niz godina 
na taj način vrši se razmena poruka u finansijskoj industriji. Paterni povezani za 
razmenu poruka detaljno su specificirani u knjizi Enterprise Integration Patterns [90] i 
sastoje se od modula čija je blok-šema prikazana na slici 103: 

• Extract; 

• Send; 

• Transport; 

• Receive; 

• Load; 

• Process. 


«component» §] 

Processor 


«component» g] 

Extractor 


-ti - Г 


«component» a 

Loader 


_ м _ 

«component» R1 




__ 

«component» R1 

Sender 




Sender 







«component» а 

Transport 


«component» 

ir 



«component» Д] 

Receiver 




Receiuer 

i 




i 


\ 

i 


\ 

_i k _ 


_ ^ _ 


«component» gfl 

Extractor 


«component» a 

Loader 



Slika 103. Blok-šema sistema za razmenu poruka 

Uočeni su sistemi bazirani na standardnim adresibilnim porukama u globalnom platnom 
sistemu na različitim organizacionim nivoima koji se mogu integrisati upotrebom 
jednog ili više sistema za razmenu poruka. 

Navedeni model je pojednostavljen prikaz hibridnog sistema za real time i odložene 
Credit Transfer i Direct Debit transakcije. Model pojašnjava sistem koji je moguće 
izgraditi i ističe mogućnosti tako kompleksnog sistema da bi se bolje razumeo kao 
kompaktna celina. Navedenim modelom se vizuelno prikazuju osobine koje smo želeli 
da postignemo, definisana je struktura i ponašanje sistema, on predstavlja uzor koji 
pokazuje kako budući realan sistem treba konstruisati. 
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6.2 Aktivnosti razvoja sistema 

Standard za analizu, zadavanje i implementaciju poslovnih sistema podržanih 
informacionim tehnologijama koji se predlaže u ovom radu rešava niz problema 
povezanih sa odgovomošću, autorizacijom i kvalifikovanošću različitih subjekata koje 
poslovni sistem sadrži. Jasno se razdvajaju uloga i zadaci u analizi, zadavanju i 
implementaciji tehnologa posla koji treba da se podrži sa informacionim tehnologijama, 
od tehnologa sa IT znanjima [53]. 

Primeri su i zadavanje procesa od strane tehnologa posla koje se opisuje u Operativnim 
pravilima i opisivanje struktura podataka u XML šemama od strane IT tehnologa. 
Operativnim pravilima se zadaje ponašanje sistema, uzevši u obzir standardne osobine 
koje treba da ispune. Tehničko uputstvo detenniniše struktum sistema, a termin plan 
definiše periodiku procesa sistema (učestalost dešavanja). Dokument Format i namena 
pomka ima zadatak da povezuje ponašanje sa stmkturom, odnosno operativna pravila sa 
tehničkim uputstvom. Šeme i instance pomka su praktični artifakti koji mogu da služe 
za implementaciju konkretnih kategorija u sistemu (formi, interfejsa, stmktura za 
prihvat konkretnih instanci sistema). Šeme pomka proističu iz dokumenta Tehničko 
uputstvo i Poslovna pravila. Šeme pomka se materijalizuju u XML formatu. U sebi 
sadrže informacije o stmkturi dokumenata i osnovnim ograničenjima nad 
odgovarajućim skupovima podataka. Instance pomka se operativno koriste prilikom 
realizacije sistema i praktičnih provera pretpostavki tokom analize i implementacije 
sistema. Stmkture podataka mogu da budu kompleksne i instance služe za provere 
osnovnih implementacionih pretpostavki. Šeme pomka i instance pomka služe kao 
osnova za generisanje artefakata elemenata sistema. Navedeni dokumenti predstavljaju 
ontološku osnovu sistema. 


Pravila i uputstva 

Naslov 

m Pravila UBS platne šeme dlrektnih zaduženja 

flj Operativna pravila za realizaciju kliringa i obračuna đirektnih zaduženja po osnovu ovtašćenja 
P) Terminski plan sistema kliringa i obračuna po đirektnim zaduženjima 
Tehničko uputstvo za poruke direktnog zaduženja 
m Poslovna pravila za poruke đirektnog zaduženja 
ff| Uputstvo o procesima, porukama i tehnološka pravila 
(13 XSD scheme 
(13 Primeri 

Slika 104. Pravila i uputstva iz Priloga 1 sa XML šemama i primerima 

Za izradu svakog dokumenta potrebno je sprovesti zasebnu analizu nekom od 
raspoloživih metodologija. Navedeni dokumenti predstavljaju i osnovne dokumente 
potrebna nadležnim organima za odobravanje rada sistema i procesa koji su na taj način 
zadati. Navedeni dokumenati su neophodan, ali i dovoljan uslov za započinjanje i 
realizaciju funkcionalne specifikacije kao prvog koraka implementacije sistema [17]. 
Predstavljeni dokumenti su zadati industrijskim standardima, zakonskom regulativom, 
normativnim aktima i drugim raznorodnim standardima koje treba uzeti u obzir 
prilikom analize potrebne za njihovu izradu. 
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Slika 105. Relaciona šema generisana iz paos.004.001.01 XML šeme sa sajta 


Standardna šema za predmetnu oblast može se naći na sajtu organizacije koja definišc 
pravila, recimo za direktno zaduženje, na sajtu Udruženja banaka Srbije (Slika 104.). 



□ & Н H ll šSaođ <? + 


♦ Metadata (Ontology1352567817.owl) OVVLCIasses Properties ♦ Individuals | Z Forms | DataGenie v2.0.1 | 

Data Source Туре (■) ODBC O JDBC 0 Preview 

ODBC Driver sunjdbc.odbc.JdbcOdbcDriver _ 

Data Source Name | MySQL ж 

User Login [root | 

Password 1 ******* | 


Data Tables 


@ lable 


► 11 document 

► Ш fininstnid 

► Ш header 
Ш instdagt 

► ИШ instgagt 

11 orgnltxinf 

► 11 paos00400101 

► 11 transactioninformationstatus 



Slika 106. Import šeme iz MySQL baze podataka u alat Protege 
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Izaberimo kao primer šemu paos.004.001.01.xsd. Koristi se za promenu statusa 
instrukcije direktnog zaduženja i instrukcije za refundaciju koja se odnosi na 
uključenje/isključenje ovih instrukcija iz ciklusa kliringa. Generiše je banka 
dužnika/banka poverioca i dostavlja procesoru. 



I n stđAgt_l d_INSTANCE\ln stgAgtJ đ_INSTANCE 


orgnltxinf 


instdagt 


instgagt 


ransactionlnformationStatus Id INSTANCEHeader Id INSTANCE/fleader Id INSTANCE 


ransactioninformationstatu; 




aos00400101 Id INSTANCBćaos00400101 Id INSTANCE 


paos00400101 


Document Id INSTANCE 


document 


Slika 107. Graf automatski kreirane ontologije importom iz baze podataka 



Slika 108. Kreirana ontologija i umetnuti REA elementi sa povezanim znanjem o 

klasama 
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Рошка se sastoji od zaglavlja ( Group Header ) koje nosi zajedničke informacije svih 
instrukcija kojima se menja status u ciklusu kliringa i tela рошке ( Transaction 
Information) koje nosi informacije o pojedinačnim instrukcijama kojima se menja status 
u ciklusu kliringa. Korišćenjem alata xsd2db [192] dobija se relaciona šema рошке, kao 
što je to prikazano na slici 105 [108]. 

Primenom alata DBConvert relaciona šema se iz MSSQL server baze konvertuje u 
MySQL bazu podataka, iz tehničkih razloga jer alat koji će se kasnije koristi ne 
podržava MS SQL server [122]. Koristeći alat Protege importujemo šemu preslikanu u 
MySQL [223], kao što je prikazano na slici 106 [35]. 

Kreiranjem grafa dobija se reprezentacija ontologije, prikazana na slici 107. 
Dodavanjem REA elemenata kreiranoj ontologiji i znanja o odnosima klasa 
(superklasa/potklasa) dobijamo ontologiju prikazanu na slici 108. 

Na dobijenu ontologiju može biti primenjena REA proširena ontologija na način kako je 
to u prethodnom paragrafu opisano, na primer sa lokacijom ili ugovorenom obavezom. 

6.2.1 Kreiranje lokalnih ontologija i domenske ontologije 

Ontologije se bave fenomenima kao što su uopštenje vremena, prostora i uzročnost ili 
domena u određenom domenu i mogu se primeniti u elektronskom poslovanju i 
metodologijama modelovanja [79]. Ontologije, kao formalni opis objekata, njihovih 
osobina i odnosa u određenom domenu eksplicitno su razumljive i za čoveka i računar. 
Ontološkim pristupom se postiže interoperabilnost i konzistentnost u modelu i 
obogaćuje dizajn modela sa domena znanja [89]. Svaka poslovna transakcija je praćena 
sa jednom ili više finansijskih transakcija, pa tako standard ISO 15944-4:2007 definiše 
ontološko okruženje za specifikaciju koncepata i relacija uključenih u poslovne 
transakcije i scenarije nazvane Resource-Event-Agent (REA) ontologijom [29]. REA 
opisuje punu ekonomsku razmenu vrednosti u kolaborativnom prostoru kao definisanu 
poslovnu transakciju. REA može da se upotrebi kao ontološki okvir za uvođenje 
osnovnih entiteta i odnosa koji su uključeni i u poslovne transakcije i scenarije za 
modelovanje interoperabilnih sistema elektronskog poslovanja platnih sistema. 

Platni sistemi u svakoj ekonomiji imaju ključnu ulogu [203] jer obezbeđuju mehanizme 
uz pomoć kojih se vrši izvršenje finansijskih transakcija. U svim segmentima je prisutna 
raznolikost standarda: hardver, softver, kadrovi, organizacija, podaci, standardi za 
рошке. Platni sistemi, po vertikali, od centralne banke, preko klirinških kuća, banaka i 
drugih finansijskih organizacija, do korporativnih i Retail korisnika moraju da budu u 
međusobnoj interakciji [15] i interakciji sa drugim sistemima koji prate finansijsku 
razmenu - kao dualnu REA transakciju [10]. 

U platnim sistemima korišćenje poruka ima ulogu na nivou razmene podataka, odražava 
se na aplikativne modele sistema i operacije u sistemu izazvane događajem [102]. Na 
nivou razmene рошка transportni mehanizam omogućava korišćenje posebnih modula 
za razmenu рошка i njihovu obradu. Upotrebom sistema za razmenu рошка ostvarujc 
se pouzdanost u komunikaciji, transparentnost u odnosu na programske jezike i 
platfonne, postiže se asinhronost koja omogućava modulima nezavisnost obavljanja 
operacija bez gubljenja vremena na čekanje izvršenja operacija drugih modula. Postiže 
se i mogućnost tjuniranja vremena obrade u odnosu na kapacitete, odstranjuju se 
zaglušenja i onemogućavanje rada modula prouzrokovanih prevelikim brojem poziva 
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operacija modula. Interoperabilnost se postiže korišćenjem standardizovanih sistema 
poruka, transportnih sistema za njihovu razmenu, a omogućava učesnicima standardan 
pristup operacijama sa finansijskim i poslovnim transakcijama. Koordinacija između 
učesnika u platnom prometu unutar države je suštinska za postizanje konzistentnosti i 
efikasnosti elektronskog poslovanja. Postiže se standardizacijom na svim nivoima [47]. 
Upotreba globalnih finansijskih standarda u domenu platnih sistema unapređuje 
konzistentnost i efikasnost elektronskog poslovanja i doprinosi unapređenju sistema za 
elektronsko poslovanje i drugih sistema. Glavni faktor uspešne implementacije platnih 
sistema na državnom i međunarodnom nivou predstavlja uspostavljanje višeslojne 
interoperabilnosti elektronskog poslovanja u skladu sa globalnim standardima. 

Platni sistemi u procesu elektronskog poslovanja [104] u interakciji su sa različitim 
poslovnim sistemima učesnika [162]. Poslovni sistemi učesnika podržavaju veliki broj 
korisnika i poslovnih procesa sa specifičnim zahtevima [78]. Osnovni problem je 
heterogenost poslovnih procesa, podataka i korišćenih IT tehnologija. Razmena 
finansijskih transakcija elektronskim putem je prevladavajuća. Standardizacija u 
domenu modeliranja platnih sistema, koja će biti razmatrana, treba da doprinese većoj 
efikasnosti ostalih sistema elektronskog poslovanja i interoperabilnosti elektronskog 
poslovanja učesnika. Registraciono telo koje se predlaže u ovom radu ima zadatak da 
arhivira poruke i potvrde prijema i da na taj način za treća lica, na specijalan zahtev, 
recimo potrebe veštačenja, učini poslovne procese elektronskog poslovanja sledljivim i 
neporecivim. 


Ч»И«1 

▼ #Thing 

▼ •Economic_Agent 
▼ • Financiallnstitution 

▼ •Bank 

[ •CreditorBank 

• DebtorBank 
T •Payments_Agent 

• CreditorAgent 

• DebtorAgent 

• Forwarding_Agent 

• lntermediary_Agent 
V •Processing Agent 

• Central_Bank 

• Payment_House 
T •Message Transporter 

• Message_Receiver 

• MessageRouter 

• Message_Sender 
т •Retail Person 

T •citizen 

• CitizenCreditor 

• CitizenDebtor 

• Citizen_Ultimate_Debtor 

▼ •Legal Person 

• LegalPersonCreditor 

• LegalPersonDebtor 

• Le g al_P e rs o n _U I iti m ate_D e bto r 


Slika 109. REA, Lista ekonomskih agenata 

Na slici 109. prikazani su ekonomski agenati platnog sistema jedne REA ontologije 
[219]. Kao ekonomski agent prikazan je i Message_Transporter sistem odgovoran, 
autorizovan i kvalifikovan za proces razmene poruka. Predstavljeni su na istom nivou 
pravno i fizičko lice kao Retail_Person jer u iniciranju transakcija imaju istu ulogu, 
razlikuje se samo zakonska osnova koja je, kad se prikažu na ovaj način transparentna u 
odnosu na iniciranje transakcije. 
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▼ •Thing 

► • EconomicAgent 
▼ € Economic Event 

• Booking_Executed_External_Transaction 

► •Canceling 

• Collecting External Response Document 

• Contracting 
▼ #Creating 

• Creating_Account_Balance_Report 

• C re ati n g_E xte rn al_P ау m e ntl n stru cti o n 

• C re ati n g_P ау m e ntl n stru cti o n 
▼ •Creating_Statment_Report 

• CreatingDetailedStateme ntofAc c o u nt 

• Creating_lnterim_Statement_of_Account 

• Creating_Statement_of_Account 

• Ех ctracti n gTran s acti o n 

• FundsTransfering 

• Payment_lnitialization 

► •Query 

• Realizing_External_Payment_lnstruction 

► •Realizing_lnternal_Payment Instruction 

• Realizing_lnternal_Payment_Transaction 

• Using_Payment_lnstrument 

► •Economic_Resource 

Slika 110. REA, Lista ekonomskih događaja 

U ontologiji prikazanoj na slici 110. korišćeni su događaji inicirani porukama različitog 
tipa, koji mogu biti: Creating ( Add) za kreiranje nove instance objekta, Inquiry za 
pribavljanje informacija o stanju određenog objekta, Submit koji je informativan i ne 
zahteva određene privilegije, Modification za izmenu instance ili objekta, Cancellation 
za otkazivanje postojeće instance objekta, Renewal za obnavljanje instance ili 
postojećeg objekta, Reinstatement za instanciranje postojećeg objekta, Reissue da 
prepiše instancu od postojećeg objekta, Quety ( Synchronization ) da obezbedi instancu 
specifičnog objekta od strane Servisa provajdera usluge. 

U do sada korišćenoj REA ontologiji, ekonomski resursi su platna instrukcija, platna 
transakcija i platni instrument. Instrumenti plaćanja determinišu tip platnih instrukcija 
koje će biti upotrebljene prilikom njihove realizacije, platne transakcije koje će biti 
izvršene, kao i način na koji će se izvršenje obaviti. 



► • EconomicE vent 
т • Economic Resource 


▼ •Payment_lnstruction 

▼ •MT 

► •MT102 

• MT103 

• MT202 

▼ ®MX 

▼ • Payments_Clearing_and_Settlement 

• FI_To_FI_Customer_Credit_Transfer 

• F l_To_F l_C u sto m e r_D i re ct_D e b it 

• F l_To_F l_P ау m e nt_Re v e rs al 

• Financial _lnstitution_Credit_Transfer 

• Payment_Return 

► •Payments_lnitiation 

▼ •Payment_Transaction 

T • Defered Transaction 

• Credit_Transfer_Transaction 

• Direct_Debit_Transaction 
• RealTimeTransaction 

▼ •Pyment_lnstrument 
► •CrossBorder 

▼ •Domestic 

• CashReceivables 

• CashTransfer 

• CreditTransfer 

• Direct Debit 


Slika 111. REA, Lista ekonomskih resursa 

Kod platnih instrukcija, na slici 111. prikazani su standardi ISO15022 (MT) [208] i 
IS020022 sa nekoliko vrsta platnih instrukcija. Prikazana ontologija prati logiku zadatih 
standarda i verzije standarda. Platne transakcije koje su predstavljene su odložene 
transakcije i transakcije u realnom vremenu, i predstavljaju ekstrahovane platne 
transakcije iz platnih instrukcija. Izborom odgovarajućih agenata, resursa, Event -a iz 
prikazane ontologije, po finansijskoj vertikali (inicijator plaćanja, banka, agent/klirinška 
kuća ili druga finansijska organizacija, sistem centralne banke) vrši se izbor: standarda 
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рошка, sistema za iniciranje plaćanja, sistema za razmenu, sistema za pretprocesiranje i 
sistema za procesiranje. Sve klase su potklase osnovne klase Thing. R-E-A klase su 
Resource, Event i Agent. Korišćen je koncept poslovne kolaboracije, gde se razmena 
vrednosti vrši putem Message_Transportera. Navedene klase, sa svojim potklasama 
prikazane su na slici 112. Economic agenti su finansijskc institucije, inicijatori plaćanja, 
koji su predstavljani kao Retail_Person i medijator za prenos рошка. 


ВИНЕШД—ШИЈШ 

kBB _ 

▼ •Thing 

► #Economic_Agent 

► #Economic_Event 

► •Economic_Resource 



▼ •Thing 

▼ #Economic_Agent 

T #РтапсјаМп51ј1и1Јоп 

▼ € Bank 

• CreditorBank 

• DebtorBank 

▼ •Payments_Agent 

• CreditorAgent 

• DebtorAgent 

• Fonvarding Agent 

• lntermediary_Agent 

▼ •Processing_Agent 

• Central_Bank 

• Payment_House 

▼ • Message_Transporter 

• MessageReceiver 
>Message_Router 

• Message_Sender 

▼ •RetailPerson 

► •Citizen 

► •Legal Person 


шш 






▼ »Thing 

► < Economic Agent 
▼ C EconomicEvent 

• Booking_Executed_External_Transaction 

► •Canceling 

• Collecting_External_Response_Document 

• Contracting 

► •Creating 

• FundsTransfering 

• Payment_lnitialization 

► #Query 

• Realizing_External_Payment_lnstruction 

► • Realizing_lnternal_Payment_lnstruction 

• Realizing lnternal Payment_Transaction 

• Using_Payment_lnstrument 


▼ Thing 

► •EconomicAgent 

► i&EconomicEvent 

▼ •Economic_Resource 
T •Payment_lnstruction 
; ► ®мт 

► ®мх 

▼ •Payment_Transaction 

T • Defered Transaction 

• CreditTransferTransaction 

• DirectDebitTransaction 
• Real_Time_Transaction 

▼ •Pyment_lnstrument 

► •Cross_Border 

► •Domestic 


Slika 112. Predstavnici klase ,,Thing“ i njihove potklase domenske ontologije 


Agenti su odgovomi za rukovanje objektima sistema koji su u njihovom vlasništvu i 
inicijatori su događaja u sistemu, dakle oni koriste resurse i iniciraju događaje. Agenti u 
sistemu su učesnici iz finansijskih standarda, na primer IS020022 ili ISO15022. 
Message_Transporter je takođe određen da bude agent jer je odgovoran, autorizovan i 
kvalifikovan za specijalizovano rukovanje objektima, odnosno za slanje, mtiranje i 
prijem finansijskih transakcija koje su zapakovane u platne instrukcije, tj. za mkovanje 
objektima nad kojima mu je predata jurisdikcija. 


Message_Transporter u mčno-manipulativnim sistemima bila bi osoba koja bi obavljala 
poslove dostave sa zapisom o primopredaji pošiljke, baš kao što je to u ovom slučaju. 
Sistem Message_Transporter je specijalizovana elektronska pisamica za predmete 
posebne namene. Banka kreditora i banka debtora predstavljene su kao dva agenta jer su 
im po poslovima koji su im dodeljeni suštinski različiti poslovni procesi, skupovi 
podataka i način na koji se oni distribuiraju. Ista stvar je i sa agentima plaćanja, 
agentima koji imaju zadatak da proslede ili one koji su samo posrednici u transakcijama. 
Centralna banka i klirinška kuća vrše finalno procesiranje [42], klirinška kuća na nivou 
poravnanja finansijskih transakcija [28], a centralna banka [33] za bruto poravnanje u 
realnom vremenu. Događaji su sve pojave mogućih finansijskih operacija [140], [154] 
koje mogu da se obavljaju. Ekonomski resursi su svi objekti koji se javljaju u polovnim 
procesima elektronskog poslovanja platnih sistema. Kao i za agenta i događaj, u 
ekonomske resurse se preslikavaju svi standardizovani objekti u dostupnim standardima 
finansijske industrije, u ovom slučaju ISO15022 i IS020022. Sve pomke, koje u sebi 
nose platne instmkcije, tipovi standardizovanih transakcija, i standardizovani platni 
instmmenti klasifikovani su u ekonomske resurse. Po pitanju stmkture, resursi su 
nosioci. Standardizovane stmkture podataka, stmktura klasa iz IS020022 pomke 
Udmženja banaka Srbije (pacs.003.001.01), preslikavaju se u stmkture ontologije. 
Debtor i Creditor su Retail Person koja je predstavljena kao ekonomski agent. Lokalna 
ontologija se izvodi iz domenske izborom odgovarajućih klasa, kao što je to prikazano 
na slici 113 za inicijalizaciju transakcije direktnog zaduženja. 
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т Thlng 
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Slika 113. Izvođenje lokalne ontologije izborom odgovarajućih klasa 

6.2.2 Razvoj scenarija 

Scenario razvoja i implementacije sistema elektronskog poslovanja platnih sistema 
sastoji se od izbora standarda, segmenta standarda koji se odnosi na zadatu oblast 
poslovanja, izbora nivoa na kom se vrši implementacija i razvoja i implementacije 
izabranom metodologijom [19]. Može se pokazati da je za sisteme zadate 
standardizovanim adresibilnim porukama sa poslovnom logikom scenario razvoja i 
implementacije isti [40]. Ukoliko neki sistem nije zadat standardizovanim adresibilnim 
porukama, može se pre procesa razvoja i implementacije izvršiti odgovarajuća 
standardizacija i razvoj i implementacija će se svesti na prethodni slučaj. 

6.2.2.1 Izbor standarda 

Izbor standarda kod elektronskog poslovanja vrši finansijska institucija koja se nalazi na 
najvišem nivou; uobičajeno je da standarde zadaje i propisuje njihovu upotrebu 
centralna banka za sve nivoe finansijskih institucija [76]. Posredno se vrši i zadavanje 
putem regulative i standardizacija Retail nivoa,odnosno nivoa za pravna i fizička lica. 
Prilikom izbora standarda vodi se računa o postojećim standardima koji su u opticaju i 
rizicima uvođenja željenog standarda. Rizici su izraženi na takav način da obuhvataju 
kreditni rizik, rizik likvidnosti, operativni rizik i sistemski rizik. 

6.2.2.2 Izbor segmenta standarda 

Standardi platnih sistema obuhvataju uvek više segmenata elektronskog poslovanja 
platnih sistema i nije uobičajeno zbog velikih rizika da se vrši implementacija svih 
segmenata istovremeno. U odnosu na segment poslovanja vrši se analiza objekata u 
sistemu i poruka koje su povezane sa tim objektima. Poruke u sebi nose događaje za 
kreiranje novih instanci objekata u sistemu, za izmenu objekata u sistemu, za storno 
objekata u sistemu (operacija brisanja instanci objekata u finansijskoj industriji ne 
postoji, već instance koje treba da budu obrisane bivaju označene sa ,,obrisan“) i razne 
vrste pogleda na sistem koje se, takođe, obavljaju porukom i na zahtev. U odnosu na 
objekte, vrši se izbor standardizovanih poruka, poruke se grupišu u procesne celine koje 
će biti zasebno realizovane. Razlika kod implementacije je u funkcionalnostima 
procesiranja, ostali segmenti su isti i realizuju se jednom i zajednički su resurs za sve 
grupisane procese. 
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6.2.2.3 Izbor nivoa 

Izbor nivoa je bitan samo u segmentima za nivo koji spadaju u njegovu isključivu 
nadležnost: 

• Retail; 

• nivo banke; 

• nivo llnansijskc institucije; 

• nivo agenta; 

• nivo klirinške kuće; 

• nivo centralne banke; 

• nivo finansijskc institucije za poravnanje Foreign Exchange - FX instrukcija. 

Razlika između nivoa može biti u načinu izuzimanja sredstava sa računa (recimo da se 
određenom računu izuzmu dve sume, jedna koja je inicirana i druga koja prestavlja 
naknadu za izvršenu uslugu procesiranja inicirane transakcije), obaveze izveštavanja 
zainteresovanih strana na određen način, operacija koje treba da budu obavljene da bi 
mogla da se izvrši naplata usluga i generisanje knjigovodstvenih stavki, načina puštanja 
transakcija. Recimo u bankama postoji tačka sinhronizacije poslovanja ili upravljanje sa 
likvidnošću, gde se sve transakcije ili samo deo transakcija povremeno ili stalno 
zadržavaju u odnosu na količinu sredstava kojima banka raspolaže, a takav je slučaj i u 
drugim finansijskim sistemima. Samo izuzimanje sa računa, saldiranje, poravnanje i 
druge operacije iste su u svim sistemima na svim nivoima , vrše se nad istim objektima i 
na isti način. 

6.2.2.4 Razvoj po nivoima 

Na svim nivoima komponente sistema u nastavku su jednake: 

• transport poruke; 

• prijemporuke; 

• pretprocesiranje poruke; 

• postprocesiranje poruke; 

• korišćenje servisa Registracionog tela. 

Razlika se pojavljuje isključivo u modulu za procesiranje koji treba da se posebno 
razvija za sve nivoe prema profilu institucije i njenim proizvodima i uslugama koje 
pruže svojim klijentima. Već prilikom zadavanja standarda ili proučavanjem već 
zadatog standarda potrebno je uraditi odgovarajuću analizu i determinisati modele koje 
treba razviti i implementirati, kako od strane finansijske institucije, tako i od 
proizvođača rešenja. 

6.2.3 Ključni indikatori performansi 

Postoje dve kategorije PKI koje mogu da budu razmatrane u elektronskom poslovanju 
platnih sistema [115]: 

• PKI sistema 

• Standardni elementi PKI poslovanja. 

Lemerov prikaz sistema [111], slika 114, prikazuje sistem i sredinu. Sredina u slučaju 
elektronskog poslovanja platnih sistema je unija dmgih sistema elektronskog 
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poslovanja, jedan od njih je nadređeni, neki su na istom nivou, dok su drugi podređeni 
sistemi [184]. Na istu sliku nailazimo i prilikom strukturne sistem analize sistema (na 
primer na konteksnom SSA dijagramu); nalazimo da sistem sa sredinom razmenjuje 
informacije preko interfejsa, nadređenog sistema, ravnopravnih i podređenog sistema. 
Jedan sistem drugom predaje informacije bitne za izvršavanje upravljačkih radnji i za 
upravljača i upravljanje sistemom [156]. I drugi sistem prima informacije (indikatore 
potrebne za upravljanje, iz kojih za svaki sistem posebno mogu da se izdvoje 
odgovarajući PKI), koje su takođe bitne i iniciraju izvršenje upravljačkih radnji [221], 
pa odatle sledi da uvek postoji i drugi sistem koji je dualan onom koji smo inicijalno 
posmatrali i da svaki sistem ima svoj dualan sistem: jedan nadređeni i drugi podređeni, 
odnosno upravljani i upravljački. 



Slika 114. Lerner: Sistem i sredina 
Y - ulazna dejstva, X - izlazna dejstva 

Upravljački sistemi koriste u značajnoj meri one upravljačke informacije koje su 
indicirane sa PKI. Skupovi informacija [190] koji razmenjuju upravljani i upravljački 
sistem u cilju obavljanja osnovne delatnosti i upravljanja funkcionišu na principu 
razmene potpunog sistema poruka, od kojih je jedan deo vlasništvo upravljanog sistema 
a drugi sistema koji upravlja. Pošto su sistemi poruka i vlasništvo jednog i drugog 
sistema, oba sistema moraju da budu sposobna za razmenu i procesiranje poruka i iz 
jednog i iz drugog sistema, pa samim tim moraju da imaju istu strukturu. Oni veštački 
mogu da imaju drugu pojavnost, odnosno da na različit način procesiraju i predstavljaju 
elemente istih poruka, i to ne prestavlja optimalno rešenje. Odatle sledi da oba navedena 
sistema moraju da imaju istu strukturu. Elementi elektronskog poslovanja u najvećoj 
meri su u direktnoj zavisnosti od upravljačkih PKI, kompoziti su i sačinjeni od jednog 
ili više upravljačkih PKI, ali su lakše merljivi [46]. Za elektronsko poslovanje platnih 
sistema za merenje perfonnansi od značaja su: 


• kvalitet; 

• troškovi; 

• prilagodljivost; 

• potražnja; 

• brzina; 

• inovativnost servisa. 


6.2.4 Izbor metodologije razvoja i implementacije 

Cilj projektovanja je, najčešće, idealna varijanta informacionog sistema. U tu svrhu se 
koristi veliki broj različitih metoda. U ovom poglavlju će biti razmatrani različiti aspekti 
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optimizacije procesa projektovanja i izbora strategije projektovanja informacionih 
sistema i jedan od mogućih pristupa optimalnom projektovanju informacionih sistema. 

Mnogobrojne knjige i radovi posvećeni su pitanju optimizacije. Njihovi autori su 
uglavnom matematičari, a njihova osnovna tema su matematički aspekti postavljanja i 
rešavanja zadataka optimizacije. Savremena teorija optimizacije pokušava da 
uvođenjem novih metoda odgovori na zahteve stručnjaka iz različitih oblasti, nažalost sa 
polovičnim uspehom. Naime, fonnalne metode ne odražavaju realnu situaciju u kojoj se 
nalaze projektanti, tako da postoji sve veća potreba za novim i boljim metodama koje bi 
omogućile optimizaciju samog procesa projektovanja. Pored velikog broja metoda za 
projektovanje informacionih sistema, ne postoji efektivna formula za izračunavanje 
optimalne strategije u izboru i primeni u projektovanju informacionih sistema. U 
najboljem slučaju prisutne su samo naznake prednosti i mana pojedinih metoda 
projektovanja, bez dubljeg uvida u problem optimalnosti projektovanja informacionih 
sistema. 

Sa matematičkog stanovišta, problem optimizacije svodi se na sledeće: data je funkcija 
F(X) za koju treba pronaći maksimum, a da pri tome X zadovoljava uslov A(X)<=B. 
Pritom X i B treba posmatrati kao višedimenzione vektore, a F i A kao funkcije nad 
vektorima, bez ikakvih daljih ograničenja. Pojedine vrednosti u vektoru predstavljaju 
vrednosti parametara koji utiču na optimalnost odabrane funkcije. Ako izaberemo 
odgovarajuća ograničenja za tip funkcije F(X) i dodamo odgovarajuća ograničenja na 
skup dozvoljenih vrednosti promenljive X, dobijamo pojedine zadatke optimizacije koji 
su u opštem slučaju rešeni i imaju odgovarajuće nazive i metode za rešavanje. 

Opisno definišimo specijalni slučaj problema optimizacije procedure projektovanja 
infonnacionog sistema. Dclinišimo najpre ciljnu funkciju procedure projektovanja 
informacionog sistema: F(X) možemo da iskažemo numerički, kao linansijski rezultat 
projektovanja, realizacije i implementacije zadatog informacionog sistema. Ukoliko 
posmatramo već projektovani i implementirani infonnacioni sistem vrednost ciljne 
funkcije (i meru optimalnsti) vrlo grubo možemo da izrazimo na sledeći način kao u 
fonnuli (4): 


(4) 


F(X)=A(X)-B(X) 


gde je A(X) finansijski rezultat primene informacionog sistema u toku njegovog 
životnog ciklusa, a B(X) ukupni troškovi njegove primene. Za poređenje različitih 
varijanti X, dovoljno je izvršiti procenu vrednosti F(X;) i jednostavno izabrati 
najpovoljniju. Ukoliko projektujemo novi informacioni sistem, problem je što u 
trenutku izbora strategije projektovanja ne postoji dovoljno informacija za rešavanje 
problema. Tada moramo da obratimo posebnu pažnju i na vrednost troškova 
projektovanja sistema. Ali ni ova vrednost ne obuhvata samo cenu izrade projekta. 
Treba imati u vidu i izgubljenu dobit u toku projektovanja i realizacije projekta (faktor 
vreme) i naročito mogućnost neuspeha (izraženu preko verovatnoće uspeha projekta ili 
još bolje preko raspodele verovatnoće uspeha projekta u odnosu na vreme i stepen 
realizacije projekta). U slučaju neuspeha treba uračunati troškove projektovanja i 
realizacije sledeće varijante projekta. Funkcija cilja, dosta pojednostavljena, u ovom 
slučaju dobija oblik kao u formuli (5): 


(5) 


F(X)=(A(X)-B(X) - C(X))*p(X-) - (B(X)+C(X)+F(X,))*(l-p(X)) 
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gde su C(X) troškovi projektovanja informacionog sistema X, p(X) verovatnoća 
uspešne realizacije, a Xi nova varijanta, koju moramo da projektujemo u slučaju 
neuspeha. Očigledno, zanemarili smo moguće komplikacije sa delimičnim uspehom i 
raspodelom verovatnoće uspeha, odnosno delimičnog uspeha u vremenu. Kada na 
komplikovanu ciljnu funkciju dodamo niz ograničenja koja se odnose na različite 
aspekte kao što su vreme, finansije, hardver, softver, kadrovi, standardi i spisak želja 
investitora, dobijamo zadatak čije bi teorijsko rešavanje, blago rečeno, zahtevalo 
ogromne resurse i neograničeno vreme uz neizvestan uspeh . 



Slika 115. Ciljna funkcija i ograničenja 

Na slici 115. prikazana je grubo pojednostavljena prezentacija ciljne funkcije i 
ograničenja procedure projektovanja informacionog sistema. Osenčena oblast na slici su 
dozvoljeni pristupi projektovanju informacionih sistema. Oko tačke L nalaze se 
optimalni pristupi projektovanju. 

Pošto smo zaključili da matematičko razmatranje problema optimizacije projektovanja 
infonnacionih sistema može da bude strahovito komplikovano i da nije svrsishodno, 
pokušaćemo da problem rešimo procenom dejstva pojedinih ograničenja. Procena je da, 
u stvari, bolji ukupan rezultat daje informacioni sistem u okviru zadatih ograničenja, 
koji se brzo i sigumo projektuje i realizuje, čak i ukoliko sam za sebe nije optimalan u 
odnosu na ,,savršen“ infonnacioni sistem, za koji je vreme projektovanja veće i 
verovatnoća uspešne realizacije manja. Za optimalnost informacionog sistema, takođe, 
veliki značaj ima njegova prilagodljivost novonastalim situacijama i standardima. 

Sa stanovišta naručioca, postaje očigledno da idealno rešenje, koje samo za sebe daje i 
najbolji rezultat, ukoliko uzmemo u obzir i sam proces projektovanja, ne mora da bude, 
i najčešće nije, optimalno. I sa ovog stanovišta, nameće se ideja da je vrlo blizu 
optimuma svaka metoda koja brzo i uz minimalni rizik daje zadovoljavajuće rešenje, 
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koje se uz to može cilkasno prilagođavati novim zahtevima. Pritom naročito treba imati 
u vidu još jedan skup ograničenja: skup relevantnih standarda koji se odnose na oblast 
primene informacionog sistema i/ili na tehnička rešenja koja treba primeniti. 

Standardnim metodama najveći problem predstavlja faza prikupljanja i analize zahteva. 
Metode u kojima se intervjuima i sličnim istraživanjima utvrđuju potrebe pre svega su 
izuzetno spore (vreme je novac), a zatim i vrlo neprecizne. Često dobijamo masu 
protivrečnih, tenninološki neusklađenih i po važnosti neizbalansiranih zahteva. Pored 
gubitka na vremenu, tokom projektovanja velika je verovatnoća da i sama realizacija 
potraje neplanirano dugo i/ili da se završi neuspehom. (Odgovarajući statistički podaci o 
uspehu projekata mogu se utvrditi i može im se manje ili više verovati). 



POZICIJE VREDNOSTI 


Pozicija 

Pozicija 

vrednosti 



o o o | 




Slika 116. Od standarda do implementacije 

Drugu krajnost predstavljaju RAD metode, koje kroz saradnju sa krajnjim korisnikom, 
odnosno tehnologom posla, brzo daju prototip koji se dalje razvija ili napušta. Sa 
stanovišta vremena, situacija je bolja ukoliko projekat uspe, ali je zato verovatnoća 
neuspeha prototipa velika. Posebno je velika opasnost da se dobije samo delimično 
rešenje problema, koje se teško može dovršiti ili prilagoditi novonastalim situacijama. 

Osnovni problem je analiza sistema, u kojoj korisnik često može da odmogne namećući 
svoje ,,želje“ umesto stvamih potreba. Pretpostavka je da je pravi pristup analiza 
standarda koji se odnose na posmatrani sistem i pozicija vrednosti koje ti standardi 
prate. Standardima se određuju pozicije vrednosti koje se prate, način njihovog 
menjanja, način kontrole i eksploatacije podataka o pozicijama vrednosti, kao i način 
odlučivanja u sistemu. 

Tabelom 19. data je komparativna analiza faza razvoja sistema po nekim prihvaćenim 
metodologijama sa predloženim pristupom. Uočljivo je da RAD-CADM daje prototip 
koji može da bude zadovoljavajući (ali ne mora, što RAD svrstava u gmpaciju 
„rizičnih” metoda), a da aplikacija dobijena našim pristupom mora da bude 
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zadovoljavajuća jer proističe iz standarda poslovanja. Analiza je sačinjena u predistoriji 
sistema tako da je u predloženom pristupu dovoljna konstruktivna analiza standarda iz 
koje proističe definisan fizički model podataka nad kojim se razvija aplikativni nivo. 

Odabrani skup pozicija vrednosti koji se prati direktno determiniše implementaciju 
informacionog sistema, uzevši u obzir zadate odluke i standarde (slika 116.). On je 
determinisan u svakoj fazi implementacije sem predistorije sistema jer u fazi analize 
standarda postoji odluka na osnovu standarda (taj standard je uglavnom maksimiziranje 
dobiti od rada informacionog sistema) za utvrđivanje redosleda važnosti pozicija 
vrednosti po nekom kriterijumu. Na osnovu tog redosleda, u zavisnosti od 
raspoloživosti resursa informacionog sistema i sistema uopšte (na primer raspoloživost 
finansijskih sredstava, raspoloživosti kadrova i sl. ) pristupa se analizi standarda 
pojedinih pozicija vrednosti u sledu. Na taj način smo obezbedili i mogućnost 
parcijalnog pokrivanja poslovnih procesa. Nakon toga, taj deo informacionog sistema 
možemo realizovati definisanjem fizičkog modela podataka, eventualnom migracijom 
podataka, razvojem aplikacija i implementacijom. 

• u fazi definisanja fizičkog modela podataka nije neophodna parcelizacija, izuzev 
možda kod izuzetno velikih sistema, sa velikom distribuiranošću podataka i 
drugim sličnim pretpostavkama; 

• migracija podataka takođe može da se razmatra u prethodnom svetlu, no ona je 
uglavnom čvrsto definisana prirodom podataka i tabelama entiteta 
ekstrahovanim iz odgovarajućih pozicija vrednosti; 

• razvoj aplikacija je čvrsto determinisan pozicijama vrednosti koje aplikacije 
prate; 

• implementacija čvrsto je determinisana prirodom pozicija vrednosti i za 
implementaciju važi slično kao i za analizu standarda. 


CADM 

RAD - CADM 

Predloženi pristup 



Predistorija sistema 

Utvrđivanje strategije 

Utvrđivanje strategije 


Priprema analize 



Analiza 

Analiza 

Analiza standarda 

Priprema dizajna 



Dizajn 



Razvoj 

Defmisanje fizičkog modela podataka 

Definisanje fizičkog modela podataka 

Migracija podataka 

Migracija podataka 

Izrada prototipa 

Razvoj aplikacija 

Dokumentovanje 



Testiranje 

Testiranje 


Implementacija 

Implementacija 

Implementacija 

Održavanje 

Održavanje 



Tabela 19. Komparacija predloženog pristupa sa CADM i RAD-CADM 

metodologijama 

Sličan način razmišljanja može se primeniti i u drugim segmentima vezanim za 
infonnacioni sistem i na taj način mogu se sistematski razrešiti neki elementi (u odnosu 
na pet navedenih procesa na slici 116.) u predistoriji sistema. 

Ukoliko je cilj sagraditi idealan informacioni sistem, projektovanje informacionog 
sistema može da bude dugotrajan proces kome, skoro izvesno, nismo sposobni da 
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sagledamo kraj. Takav informacioni sistem je poželjan, ali nije realan sa stanovišta 
projektovanja jer se u traganju za idealnim gubi dragoceno vreme, a samim tim i 
realnost implementacije i eksploatacije. Pri izboru metodologije projektovanja, svakako 
treba uzeti u obzir optimalnost procedure projektovanja informacionih sistema. 

6.3 Projektni zahtevi 

Postoji izražena potreba za kontrolom i upravljanjem platnim sistemom, od samoga 
početka - od trenutka kada se zadaju početni poslovni uslovi za rad sistema, pa do 
dokumentovanja podataka o sistemu i podataka o radu ovih sistema velike složenosti. 
Platni sistemi su u interakciji sa odgovarajućim sistemima na drugim nivoima koji 
takođe imaju svoju veliku složenost [36]. Upravljanje podređenim sistemima je 
posredno, preko pravila detrnisanih od strane nadređenog sistema. Pravila moraju da 
budu takva da se prenose po dubini na sve podređene sisteme, i na one koji nisu pod 
direktnom jurisdikcijom glavnog upravnog sistema. Interakcija između sistema mora da 
bude po predviđenom protokolu koji ima svoje visoke zahteve, koji ne smeju da budu 
narušeni ni po koju cenu, jer se radi o izuzetno važnim sistemima. Sistemi moraju da 
rade u realnom vremenu, u predviđeno radno vreme, bez obzira na uslove poslovanja, sa 
podacima koji moraju da budu neporecivi. Platni sistemi, bez obzira na nivo u 
hijerarhijskoj strukturi na kome se nalaze, treba da budu nadogradivi sa novim 
poslovnim procesima bez narušavanja stabilnosti rada postojećih poslovnih procesa. 
Platni sistemi moraju da budu u interakciji sa različitim drugim postojećim platnim 
sistemima, kao i da poseduju odgovarajuću adaptibilnost komunikacije u odnosu na 
nove platne sisteme sa kojima treba da komuniciraju. Platni sistemi, bez obzira na 
poslovni nivo na kome se nalaze, moraju da sadrže elemente koji omogućavaju rad sa 
globalnim korisnicima. Takođe, treba da budu izgrađeni u što je moguće većoj meri na 
bazi standarda (čak i po cenu uvođenja novih standarda) uključujući i permanentno 
otkrivanje standardnih elemenata i njihovu standardizaciju. Prelazak na novi platni 
sistem nad istim domenom treba da bude moguć, odnosno platni sistem ne sme da bude 
zasnovan na takvim elementima koji će onemogućiti prelazak na novi sistem. Iako su 
platni sistemi složeni, pažljivom analizom mogu se uočiti standardni elementi koji se 
mogu izgraditi i implementirati na različite ekvivalentne načine, od strane različitih 
proizvođača, sa različitim perfonnansama i to bez gubitka predviđenih funkcionalnosti. 
Rešavanje složenosti platnih sistema i njihovo upravljanje može da se reši korišćenjem 
osobina rekurzije. Razmena informacija u okviru platnog sistema i sa okolinom platnog 
sistema može da bude putem protokola, a da kao osnovna jedinica za razmenu 
infonnacija (komunikaciju) bude poruka sa definisanim klasama u odnosu na vrstu 
upotrebe informacija sadržanih u porukama. Na sadašnjem nivou razvoja IT industrije, 
postoje različite vrste alata predviđenih za razvoj i distribuciju sistema. Alatima, 
prisutnim na tržištu, ukoliko slični a potrebni za razvoj platnih sistema ne postoje, mogu 
se na lak način izraditi odgovarajući novi. 

Osnovni zahtevi koji se postavljaju pred platni sistem jesu: 

• nezavisnost rešenja od domena korišćenja; 

• stabilnost u dužem vremenskom okviru; 

• mogućnost lakog dodavanja, mogućnost modifikacija, zamena, uvećanja, 

izmene ili pripajanja funkcionalnosti; 

• lakoća skaliranja u mnogo smerova; 

• da troškovi razvoja budu niski i raspoređeni kroz vreme; 


Slobodan Babić \ Fakidtet organizacionih nauka 


221 



Doktorska disertacija: Model interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama 


• prilagodljivost; 

• neograničenost integracije; 

• neograničenost proširivosti; 

• da zahteva ograničene ili manje zahtevne resurse; 

• da ima kompletno izolovanu aplikativnu logiku; 

• minimalnost troškova održavanja; 

• stabilnost; 

• neograničenost konfiguracije i rekonfiguracije; 

• dokumentovanost izrade sistema; 

• dokumentovanost rada sistema; 

6.3.1 Projektni zadatak 

Opis funkcionalnih i nefunkcionalnih zahteva koji se propisuju za jedan ovakav sistem 
prikazan je na primeru specifikacije zahteva za Credit Transfers. European Pavment 
Council (EPC) u skladu sa jedinstvenim sistemom za plaćanje 8 marta 2006. godine 
odobrila je SEPA CREDIT TRANSFER SCHEME RULEBOOK, verziju 2.0 pod šifrom 
EPC125-05. Rulebook je iskorišćen za fonniranje spiska funkcionalnih i 
nefunkcionalnih zahteva potrebnih za formiranje specifikacije sistema koji bi bio u 
skladu sa SEPA Credit Transfers-om. 

Spisak nefunkcionalnih i funkcionalnih zahteva nije ni na koji način strukturiran i 
sačinjen je onim redom kojim su se zahtevi pojavljivali. 

Ovaj dokument sadrži i spisak aktora u sistemu radi definisanja i lakšeg razumevanja 
funkcionalnosti i nefunkcionalnosti. 

Ovaj dokument sadrži i model, i to predstavljen na onaj način na koji ga vidi EPC i koji 
može da predstavlja polaznu osnovu za izgradnju konceptualnog modela sistema. 

• Nalogodavac ( Originator) je korisnik koji inicira Credit Transfers 
instrukcijama upućenim svojoj banci. Sredstva za ovako definisan Credit 
Transfers biti će dostupna u smislu zaduženja za specificirani račun za plaćanje 
čiji je vlasnik nalogodavac. 

• Banka nalogodavca ( Originator Bank) je učesnik koji prihvata instrukcije za 
Credit Transfers od nalogodavca i radi po instrukcijama plaćanja izvršavajući 
plaćanje u korist banke primaoca i računa primaoca, u skladu sa informacijama 
obezbeđenim putem instrukcija i u skladu sa odredbama. 

• Banka primaoca ( Beneficaij Bank) je učesnik koji prima instrukcije za Credit 
Transfers od banke nalogodavca i odobrava račun primaoca u skladu sa 
informacijama obezbeđenih putem instrukcija i u skladu sa odredbama. 

• Primalac ( Beneficiarv ) je korisnik identifikovan sa instrukcijama Credit 
Transfers-a koji prima sredstva u smislu odobrenja na svom računu za plaćanje. 

• Mehanizam za kliring i poravnanje ( Clearing and Settlement Mechanisms - 
CSM) je takav da uključuje servise za poravnanje i plaćanje kao što je 
automatska klirinška kuća ili drugi mehanizam, kao što je međubankarsko 
poravnanje, poravnanje u okviru grupe, bilateralno ili multilateralno poravnanje, 
aranžman u okviru grupe među učesnicima i drugi ugovoreni načini 
kompenzacije. 
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• Banka posrednik (Intermediarv Bank ) nudi posrednički servis između banke 
nalogodavca i banke primaoca u slučaju kada banka nalogodavca nije direktni 
učesnik CSM-a. 

Pred izvođača se postavlja i sledeća tehnička specifikacija: 

Tehnička specifikacija koiu izvođač mora da ispuni 

Tehnički zahtevi sistema su skalabilnost, adaptibilnost i proširljivost, fleksibilnost, 
poverljivost i integritet. 

Skalabilnost 

• sistem se mora implementirati da bi se obezbedio (saglasno dizajnu) visok nivo 
skalabilnosti, a posebno sa aspekta uvećanog obima podataka u postojećim 
bazama podataka, prenos informacija, uvećanje broja raspoloživih servisa i 
uvećanje broja korisnika servisa; 

• obezbeđivanje skalabilnosti ne treba uticati na održavanje traženih nivoa 
sigurnosti, raspoloživosti i performansi. 

Povećanje poslovnog opterećenja sistema primarno moglo bi da bude prouzrokovano 
od: 

• povećanja količine informacija u postojećim bazama podataka infonnatičkih 
sistema koje postoje u institucijama uključenih u sistem; 

• povećanj a broj a transakcij a; 

• povećanja broja servisa; 

• povećanja složenost transakcija; 

• povećanje kompleksnosti servisa; 

• povećanje broja korisnika (krajnjih korisnika ili drugih sistema). 

Sistem mora biti implementiran na takav način da omogući povećanje kapaciteta 
procesiranja proporcionalno radnom potencijalu, bez promena u arhitekturi. 

Adaptiabilnost i proširivost 

Pojam adaptiabilnost podrazumeva sposobnost lake modifikacije postojećih 
funkcionalnosti u jednom sistemu. Proširivost podrazumeva sposobnost lakog 
dodavanja novih funkcionalnosti u jednom sistemu. Dizajn sistema obezbeđuje da se 
adaptiabilnost i proširivost ne dese po cenu opadanja sistemskih performansi 
svakodnevnog rada. Izvođač treba detaljno da elaborira kako će da implementira sledeće 
zahteve: 

• dodavanje novih usluga (servisne registre); 

• dodavanje novih tipova podataka (mogući su multimedijski i biometrijski 
podaci); 

• dodavanje novih meta opisa; 

• dodavanje novih korisnika i uloga; 

• dodavanj e novih servisa koj i potiču sa j ednog sistema za pružanj e usluga; 

• dodavanje novih servisa koji potiču sa vise sistema za pružanje usluga; 

• kreiranje novih servisa koji predstavljaju kombinaciju postojećih servisa; 

• implementacija polisa i pristup servisima; 
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• implementacija polisa i pristup podacima preko korišćenja servisa. 

Fleksibilnost 

Termin fleksibilnost definiše sposobnost obezbeđivanja usluga različitim korisnicima 
(korisnik, grupe korisnika, glupe korisnika i aplikacija) sa nekoliko različitih načina za 
dobijanje podataka. Fleksibilnost sistema se obezbeđuje preko mogućnosti da se koriste 
srodni servisi više sistema za pružanje usluga (ukoliko takvi postoje). Izvođač treba 
detaljno da elaborira kako će mapirati sledeće elemente u konkretnom rešenju: 

• tipovi korisnika; 

• servisi omogućeni u sistemu; 

• procesi koj i postoj e u institucij ama; 

• različiti servisi za različite kategorije (tipove) korisnika; 

• vidovi pristupa i/ili servisa za spoljašnje aplikacije (korisnike). 

Integritet 

Integritet infonnacija podrazumeva da se iste informacije i podaci tretiraju na isti način 
u sistemu, odnosno da ne postoji mogućnost za različito tumačenje iste informacije. U 
dizajn sistema su predviđeni medijatorski interfejsi koji treba da izvrše prilagođavanje 
formata podataka preko njihove konverzije u XML šemu. Uvek kad postoje, treba da se 
upotrebljavaju standardi za razmenu podataka. Izvođači treba da navedu koje standarde 
za razmenu podataka (multimedija, biometrija i slično) koriste u svom rešenju. Izvođač 
treba detaljno da elaborira kako će obezbediti da podaci koji se koriste budu identično 
interpretirani i mapirani sa podacima dostavljenim iz različitih sistema za pružanje 
usluga. 

Sigurnosna potraživanja sistema interoperabilnosti 

Sigumosne, odnosno bezbednosne zahteve interoperabilnosti koji su dehnisani u 
standardu ISO 17799, Sistem za upravljanje sa sigumosnom informacijama. Ovaj 
standard pokazuje sigurnost IT sistema kao rezultat dizajniranja, sprovođenja, 
mkovođenja i kontinuiranog unapređenja. 

Sigumost infonnacija: moraju se primenjivati sigurnosne polise i periodično revidirati i 
ažurirati u odnosu na rizik za namšavanje sigumosti. Polise su definisane sa: 

• opisom strana involviranih u servisu: korisnici, administratori, mkovodioci i 
kontrolna tela; 

• uloge i odgovornosti strana uključenih u obezbeđivanje servisa sa aspekta 
primene i upravljanje polisama; uloge i odgovomosti mora da su jasno 
definisane, identifikovane i periodično kontrolisane. 

Kao podršku polisama, izvođači moraju obezbediti mogućnost definisanja aplikativne 
podrške operativnim procedurama, koje prenose principe sigurnosne politike u praksi (u 
različitim tehnološkim sredinama, za različite korisnike i sistemske operatore). Glavne 
operativne procedure su: 

• procedure koje omogućavaju prikladnu zaštitu, snimanje zaštitnih kopija i 
arhiviranje definisanih servisa, koji će obezbediti mogućnost za obnavljanje 
dostupnosti servisima nakon eventualnih prekida u radu; 

• procedure za monitoring i kontrolu svih nivoa infrastmkture moraju biti 
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povezane sa postupcima za vcri fikaciju i kontrolu, što omogućuje otkrivanje i 
sleđenje preuzetih operacija pri korišćenju servisa; 

• procedure za spravljanje sa nedozvoljenim zahtevima za korišćenje usluge i 
prikladne reakcije u slučaju prestupa ili problema sigurnosti sistema; 

• procedure za autorizaciju i pristup sistemu, kao i procedura za kreiranje, 
upravljanje i brisanje korisnika; 

• procedura za primenu kriptografske zaštite; jasno se mora definisati: 

o gde, za koje poruke i kad treba koristiti kriptografsku zaštitu; 
o kako se upravlja ključevima kriptografske zaštite; 

o kako reagovati u slučaju problema sa zaštićenim porukama ili pri 
gubljenju sertifikata ili ključeva za kriptografsku zaštitu; 

• procedure za povezivanje prema postojećim informacionim sistemima u 
institucijama; postupak mora uključivati i dcfinisanjc osnovnih nivoa sigurnosti, 
periodične provere i zaštitne mere koje treba preduzeti. 

• servisi su predmet kontrole i moraju obezbediti način za sleđenje porekla i prava 
korisnika servisa; pri tome treba voditi računa o: 

o regulisanju dostupnosti usluga spoljašnjim telima; 

o opisu domena bezbednosti u saglasnosti sa nacionalnim i internim 
sigurnosnim regulativama: 

■ polisa nacionalnog nivoa, polisa određene institucije i slično; 

■ klasiiikacija informacija i odgovomosti u skladu sa evropskim 
bezbednosnim regulativama; 

■ savet Evropske unije; 

■ dcfinisanjc prava pristupa i ograničavanje pristupa podacima; 

■ clciinisanje bazičnog nivoa bezbednosti (politike poverenja) koje 
se primenjuje na sve strane koje komuniciraju sa sistemom za 
interoperabilnost elektronskog poslovanja platnih sistema. 

Moraju se obezbediti postupci za centralnu evidenciju koji obezbeđuju periodičan 
monitoring, uključujući upravljanje alarmima, pri korišćenju servisa. Važno je 
napomenuti da evidentiranje ne obuhvata same podatke, nego samo korisnike servisa, 
tip servisa i metaopisa servisa. Aktivnosti koje treba da se evidentiraju uključuju: 

• sva potraživanja za korišćenje servisa; 

• sve odgovore na potraživanje i uspešne i neuspešne; 

• meta opis servisa; 

• sve ostale komunikacije između sistema za pmžanje servisa; 

• sva logovanja korisnika i sve izvršene događaje, kao i neuspešna ili neovlašćena 
logovanja. 

Centralna evidencija mora omogućiti administratorima da slede aktivnosti po vremenu 
njihovog izvršenja i da identifikuju korisnike koji su izvršili svaku pojedinačnu 
aktivnost, i po potrebi, pomoći ovim korisnicima da identifikuju krajnje korisnike. Zbog 
toga što se nijedna aktivnost ne može izvršiti ukoliko se ne može evidentirati, sistem 
evidentiranja mora uvek biti na raspolaganju i mora predvideti 8скипс1агпо//)е/ш/; 
skladištenje podataka za evidenciju. Podaci za evidenciju se ne mogu modifikovati. 
Podaci za evidenciju se ne mogu brisati pre zakonskog datuma isticanja važnosti. 
Evidencija mora biti raspoloživa jednu godinu i treba se arhivirati najmanje dve godine. 
Svaki korisnik mora biti u mogućnosti da pregleda evidenciju svih aktivnosti izvršenih 
sa njegove strane ili aktivnosti izvršenih na njegovim podacima. Možda će trebati da se 
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evidencija transakcije korisnika vrati korisniku pa zbog toga treba obezbediti mere za 
pojednostavljenja ovog zadatka. Evidencija se isto tako može koristiti i u statističke 
ciljeve. Moraju se razviti funkcije ili alati za izveštavanje i analizu kako bi se obezbedili 
izuzeci u upotrebi i obradive informacije recenzentima. 

Autentifikacija 

Za smanjivanje rizika od neovlašćenog pristupa, potrebno je obezbediti mogućnost 
primene jakog sistema za autcntilikaciju za određene tipove ili uloge korisnika. Takva 
autentifikacija se odvija preko primene „autentifikacije u dva nivoa” koja se bazira na 
nečemu što „posedujete” i „nešto sto korisnici znaju”. Preporučena infrastruktura takve 
autentifikacije sadrži: hardverski čip (token) za potvrđivanje identiteta i lozinke. Tokeni 
su obično predstavljeni kao mobilne inteligentne kartice ili čipovi, koji nezavisno 
čuvaju i kreiraju informacije sa fimkcijom potvrđivanja. Ovi uređaji moraju biti 
zaštićeni od kopiranja i neovlašćenog rukovanja. Oni onemogućuju čitanje informacija 
sadržanih u uređaju (predstavljaju uređaje sa zaštitom protiv neovlašćenog rukovanja). 

Kontrola pristupa 

Kontrola pristupa se mora zasnovani na „potrebnim informacijama”, tako da pristup 
treba ograničiti na oblast potrebnu za izvršavanje radnih zadataka za pojedinačne 
korisničke uloge. Pravo pristupa svih korisnika mora se konfigurisati na bazi uloga i 
profila koji se upravljaju centralno. Izvođač mora obezbediti mogućnost definisanja 
aplikativne podrške za monitoring i pregledanje pristupa, sa mogućnošću periodičnih 
izveštaja za iskorišćavanje prava pristupa. 

Enkripcija podataka 

Izvođač treba da obezbedi mogućnost kriptografske zaštite na nivou poruke koja će se 
primeniti kao rezultat aktiviranja određene sigumosne polise. Pri tome, mora se izvršiti 
potvrda autentičnosti učesnika u procesu razmene pomka. 

6.3.2 Funkcionalni zahtevi 

Na osnovu analize dokumenta EPC125-05 SEPA Credit Transfers Scheme Rulebook, 
sistem treba da zadovolji sledeće fu nk cionalne zahteve: 

• da nalogodavac kompletira instmkcije Credit Transfersa; 

• da nalogodavac pošalje instrukcije Credit Transfersa; 

• da se instmkcija pošalje na način dogovoren između nalogodavca i njegove 
banke; 

• da elementi koji moraju da budu obezbeđeni od strane nalogodavca budu 
sledeći: 

■ 01 IBAN pošiljaoca kome će sredstva biti zadužena Credit 
Transfers instrukcijom; 

■ 02 Iine pošiljaoca; 

■ 03 Adresapošiljaoca; 

■ 04 Iznos transakcije u Evrima; 

■ 05 Informacije o doznaci od strane pošiljaoca primaocu sredstava 
u okvim Credit Transfers instmkcije; 

■ 07 Zahtevani dan izvršenja instmkcije; 

■ 10 Identifikacioni kod pošiljaoca; 

■ 20 IBAN primaoca koji će biti odobren; 

■ 21 Ime primaoca; 
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■ 22 Adresa primaoca; 

■ 23 BIC banke primaoca; 

■ 24 Identifikacioni kod primaoca; 

■ 41 Referenca pošiljaočeve Credit Transfers transakcije, 

• da banka nalogodavca primi potrebne informacije za inicijaciju Credit 
Transfers -а ; 

• da banka nalogodavca proveri informacije za inicijacije Credit Transfers-a; 

• da banka nalogodavca dopuni instrukcije uslovima potrebnim za njihovo 
procesiranje; 

• da banka nalogodavca uključi autentifikaciju instrukcije; 

• da banka nalogodavca proveri format BIC -а i IBAN-a; 

• da banka nalogodavca proveri prihvatljivost BIC -а i IBAN-a; 

• da banka nalogodavca na zadati dan izvršenja zaduži račun nalogodavca; 

• da nakon zaduženja računa nalogodavca pošalje Credit Transfers instrukcije 
obezbeđujući prijem od strane banke primaoca preko odgovarajućeg Credit 
Transfers mehanizma i to najranije na zadati dan zaduženja a najkasnije dva 
dana od zadatog dana zaduženja u skladu sa pravilima Credit Transfers 
mehanizma; 

• da elementi koji se obezbeđuju za slanje ka Credit Transfers mehanizmu budu 
sledeći: 

■ 01 IBAN pošiljaoca kome će sredstva biti zadužena Credit 
Transfers instrukcijom; 

■ 02 Iine pošiljaoca; 

■ 03 Adresa pošiljaoca (opciono); 

■ 04 Iznos transakcije u evrima; 

■ 05 Informacije o doznaci (opciono); 

■ 06 BIC banke pošiljaoca; 

■ 10 Identifikacioni kod pošiljaoca (opciono); 

■ 20 IBAN primaoca; 

■ 21 Iine primaoca; 

■ 22 Adresa primaoca (opciono); 

■ 23 BIC banke primaoca; 

■ 24 Identifikacioni kod primaoca (opciono); 

■ 40 Identifikacioni kod elektronske SEPA Credit Transfers šeme; 

■ 41 Pošiljaočeva referenca Credit Transfers transakcije (opciono); 

■ 42 Datum izvršavanja Credit Transfers instrukcije; 

■ 43 Referenca Credit Transfers poruke primaočeve banke 
(opciono), 

• da Credit Transfers mehanizam pošalje poruku banci primaoca; 

• da Credit Transfers mehanizam izvrši Credit Transfersa u punoj vrednosti 
najkasnije dva dana od zadatog datuma izvršenja kao deo procesa za poravnanje 
i plaćanje u skladu sa pravilima i ugovorenim modalitetima; 

• da banka primaoca primi poruku o Credit Transfersu najkasnije dva dana od 
zadatog dana izvršenja; 

• da banka primaoca proveri poruku o Credit Transfers-u; 

• da banka primaoca odobri račun primaoca; 

• da obezbedi informacije primaocu na osnovu ugovora između primaoca i ha nk e i 
to najkasnije jedan dan nakon izvršenja (znači najkasnije 3 dana od zadatog 
datuma izvršenja, izuzev u slučaju zakonskih ograničenja povezanih sa pranjem 
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novca i finansiranja terorističkih aktivnosti i ukoliko treći dan nakon zadatog 
datuma izvršenja nije radni dan): 

■ 02 Ime pošiljaoca; 

■ 04 Iznos transakcije u Evrima; 

■ 05 Informacije o doznaci; 

■ 10 Identifikacioni kod pošiljaoca; 

■ 20 Primaočev IBAN; 

■ 21 Ime primaoca; 

■ 24 Identifikacioni kod primaoca; 

■ 41 T Pošiljaočeva referenca Credit Transfers transakcije; 

■ 42 Datum izvršenja Credit Transfers instrukcije(opciono), 

• da banka nalogodavca ili kredit transfer mehanizam odbije Credit Transfers 
ukoliko nije prihvaćen za nonnalno izvršenje pre međubankarskog poravnanja, 

• da, ukoliko je Credit Transfers u trenutku kada je nalogodavac poslao 
instrukcije banci nalogodavca, banka nalogodavca mora da obavesti samo 
nalogodavca o razlogu zbog koga nije prihvaćen Credit Transfers; 

• da, ukoliko je odbijanje izvršenja učinjeno u međubankarskom prostoru poruka 
mora da sadrži sledeće podatke: 

■ R1 tip ,,R” poruke; 

■ R2 Identifikacija tipa strane koja inicira “R” poruku; 

■ R3 Kod razloga neprihvatanja Credit Transfers-a; 

■ R4 Datum izvršenja za ,,odbijena“ ili ,,vraćena“; 

■ R5 Specifična referenca banke koja inicira odbijenicu/povratnicu; 

■ Tačna kopija svih primljenih atributa poruke koja je 
odbij ena/vraćena, 

• da transferovana vrednost u odbijanju bude istovetna originalnoj vrednosti 
navedenoj u instrukcijama za Credit Transfers; 

• da poruka o odbijanju Credit Transfers -а bude poslata istim putem kojim je i 
stigla instrukcija za Credit Transfers; 

• da nema podataka koji su pridodati originalnom Credit Transfers-u; 

• da ima relevantnih podataka o inicijalnom Credit Transfers-u dovoljnih da se 
vrši veštačenje ukoliko je potrebno; 

• da se inicijalni Credit Transfers identifikuje sa originalnom referencom banke 
nalogodavca; 

• da poruka o odbijanju Credit Transfers -а sadrži i kod razloga odbijanja Credit 
Transfers-a; 

• da poruka o odbijanju bude poslata istog dana ili narednog radnog dana banke; 

• da poruka o povraćaju bude inicirana od strane banke primaoca ukoliko nije 
moguće njeno izvršenje iz nekog razloga kao što su pogrešan broj računa, račun 
ugašen i slično sa konsekvencama da račun primaoca ne može da bude odobren 
za sumu navedenu u originalnoj poruci nalogodavca; 

• da transferovana vrednost povraćaja bude istovetna originalnoj vrednosti 
navedenoj u instrukcijama za Credit Transfers; 

• da poruka o povraćaju Credit Transfersa bude poslata istim putem kojim je i 
stigla instrukcija za Credit Transfers ili da zainteresovane strane ugovore 
posebne mehanizme razmene koji mogu da se razlikuju od originalnih; 

• da nema podataka koji su pridodati originalnom Credit Transfers-u; 

• da ima relevantnih podataka o inicijalnom Credit Transfers-u dovoljnih da se 
vrši veštačenje ukoliko je potrebno; 
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• da se inicijalni Credit Transfers identifikuje sa originalnom referencom banke 
nalogodavca; 

• da poruka o povraćaju Credit Transfers -а sadrži i kod razloga odbijanja Credit 
Transfers-a; 

• da poruka o odbijanju bude poslata istog dana ili narednog radnog dana banke 
nakon izvršenog poravnanja; 

• da poruka o odbijanju inicirana od strane banke primaoca mora biti poslata banci 
nalogodavca najkasnije u okviru tri radna dana banke nakon zadatog dana 
izvršenja. 

6.3.3 Ostali zahtevi 

Na osnovu analize dokumenta EPC125-05 SEPA Credit Transfers Scheme Rulebook, 
sistem treba da zadovolji sledeće nefunkcionalne zahteve: 

• da otkloni razlike nacionalnih i vangraničnih efekata u SEPA zoni; 

• da učini SEPA plaćanja efektnim kao u nacionalnom okruženju; 

• da SEPA Credit transfers bude automatizovan; 

• da bude baziran na otvorenim standardima; 

• da bude baziran na najboljim iskustvima vezanim za STP ( Straight-through 
processing - procesiranje bez ijedne izmene originalne inicijalne forme/zapisa 
transakcije); 

• da omogući najviše bezbednosne standarde; 

• da ukloni faktore zastoja u harmonizaciji standarda i prakse; 

• da smanji rizik, 

• da smanji troškove; 

• da poveća stepen iskorišćenja resursa; 

• da omogući dalji razvoj sistema na bazi zdrave konkurencije na tržištu platnih 
servisa; 

• da uspostavi uslove za nuđenje servisa korisnicima; 

• da Credit Transfers bude realizovan po SEPA EPC125-05, EPC 170/05 CSM 
Framework i EPC029-06; 

• da bude namenjena za banke; 

• da bude namenjen za infrastrukturne provajdere koji podržavaju operacije 
bazirane na tržišnim principima; 

• da su jasno razgraničena prava i obaveze učesnika; 

• da su poruke bazirane na otvorenim industrijskim standardima; 

• da plaćanja budu izvršena za pun originalni iznos; 

• da nalogodavac i primalac budu odgovomi za svoje vlastite troškove; 

• mogućnost pune dostupnosti računa primaoca u okviru SEPA; 

• da proizvodi bazirani na šemi obezbede šansu da se izdaju i primaju nalozi u 
SEPA; 

• da postoji maksimalno garantovano vreme izvršenja (3 dana); 

• da koristi prihvaćene standarde na STP bazi; 

• da se odbijanje i vraćanje može obaviti na predvidljiv način; 

• da se odbijanje i vraćanje može obaviti automatizovano; 

• da učesnici mogu izabrati najbolji i najjeftiniji način mtiranja transakcija; 

• da izgradi ugovorene cikluse procesiranja; 
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• da podrži i druga rešenja plaćanja, posebno RTGS (Real Time Gross Settlement) 
i RTNS ( Real Time Net Settlement ) za urgentna plaćanja i plaćanja preko limita; 

• da bude u okviru SEPA po definiciji EPC (25 zemalja EU članica i Island, 
Lihtenštajn, Norveška i Švajcarska); 

• da bude u valuti EURO u SEPA a računi da budu u EURO ili drugoj valuti - 
banka nalogodavca/primaoca je odgovorna za adekvatnu konverziju; 

• da budu visokodostupan; 

• da poštuje diskreciju nalogodavca i primaoca; 

• da obezbedi 140 karaktera koji mogu biti i strukturirani za međusobno 
automatsko poravnanje nalogodavca i primaoca. 

6.4 Analiza zahteva 

Cilj analize je da se opiše poslovni model jednog primera platnog sistema nad kojim će 
se moći izvršiti generalizacija i uočiti poslovni procesi ili funkcije platnih sistema koji 
se po svojoj prirodi razlikuju od jedne do druge vrste platnog sistema [24], [10]. Uočene 
razlike između platnih sistema tada se mogu grupisati u jedan modul da bi se dobila 
struktura opšte namene ili definisati pojedinačno ukoliko se vrši komponovanje platnog 
sistema posebne namene. Time se ispunjava tvrdnja da se sistemi složeni kao sistemi za 
platni promet mogu razložiti na standardne elemente koji se mogu implementirati na 
različite ekvivalentne načine. 

6.4.1 Specifikacija CT 

Credit transfers sistem se odvija distribuirano na tri nivoa, kako je to već naglašeno u 
razmatranju EPC modela za Credit transfers. 



Legenda: 

Credit Transfers: transfer sredstava 

Credit Transfers Initiation: započinjanje transfera sredstava 
Retail System: sistem „па malo“ 

Bank’s Retail Credit Transfer System: sistem banke „па malo“ za transfer sredstava 
Retail Reporting: izveštavanje iz sistema „па malo“ 

Credit Transfers Clearing & Settlement: kliring i poravnanje transfera sredstava 

Bank’s Processor Credit Transfer System: sistem banke za transfer sredstava procesoru 

Processor’s Neto System: procesorov neto sistem 

Procesor’s Reporting: izveštavanje procesora 

RTGS Settlement: RTGS poravnanje 

Procesor’s Bruto system: procesorov bruto sistem 

RTGS Reporting: RTGS izveštavanje 


Slika 117. Credit Transfers kontekst dijagram, dva najviša nivoa 
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Prvi nivo je kod Retail korisnika, proces 1.1 na slici 117, i povezan je sa procesima 
inicijacije Credit transfers -а, kao i kod banke gde se nalazi deo sistema koji je zadužen 
za procese povezane sa Retail korisnicima. Drugi deo procesa se nalazi u procesu 2, 
naznačen sa 2.1, i on se bavi procesima koji su orijentisani ka nadređenim institucijama 
za procesiranje. Sada je vidljiv gap između dva dela sistema koji se nalaze u banci: dela 
koji je orijentisan ka podređenom Retail delu sistema i dela koji je orijentisan ka 
nadređenom delu platnog sistema, odnosno nadređenim institucijama. Gap se odgleda u 
tome da deo sistema ka podređenim institucijama ima zadatak da izvrši što veći broj 
transakcija, da bude prijemčiv za korisnike, da izlazi u susret korisnicima u 
diskutabilnim situacijama i da ih razrešava u njihovu korist, da bude marketinški 
orijentisan prema korisnicima da bi se realizovao što veći broj transakcija koji će sistem 
u banci moći da naplati. 

Sistem koji je orijentisan prema nadređenoj instituciji nalazi se u situaciji da izvrši samo 
najneophodniji deo transakcija, da pronađe diskutabilne transakcije i da ih vrati na 
reviziju zbog rizika troška koji bi pogrešna transakcija mogla da izazove, da bude 
pesimistički orijentisan prema nadređenoj instituciji koja obračunava svaku transakciju, 
pa tako da pokušava da optimizuje transakcije grupišući ih u veći broj, čekajući da ih se 
nakupi što više pre realizacije. Čak i realizaciju, deo sistema u banci koji je orijentisan 
prema nadređenoj instituciji, pokušava da izvrši što kasnije, u poslednjem trenutku, jer 
se na taj način iz banke plasira minimalna količina sredstava, a to znači više para koje 
ostaju u banci. Slična paradigma je i za procese 2.3 i 3.1 u delu platnog sistema koji se 
nalazi u procesorskoj kući, na primer u Automated Clearing House. Navedeni procesi i 
njihov osnovni položaj u platnom sistemu prikazani su na slici 117. Procesi izveštavanja 
su vezani za zakonom regulisane izveštaje kao i pogled koji vlasnik sistema nalazi 
potrebnim prilikom korišćenja sistema. 

Standardi su još uvek zadati na engleskom jeziku. U Srbiji i danas postoji veoma malo 
standarda koji su prevedeni. Ukoliko bi analize bile vršene isključivo na srpskom jeziku 
izgubio bi se u mnogim slučajevima kontekst standarda na engleskom jeziku. Iz tog 
razloga, analiza koja je urađena u ovom radu na slikama je prikazana na engleskom 
jeziku i za svaku sliku data je i odgovarajuća legenda koja ima za cilj da uvede termine 
koji su uobičajeni na srpskom jeziku. Na sajtu Narodne banke Srbije ne postoji rečnik 
osnovnih termina na stranim jezicima sa zadatim službenim prevodom na srpski jezik. 

Retail sistem, odnosno proces 1, prikazan je na slici na slici 118. Proces 1.1.1. Payment 
preparation može da bude izvršen i ručno, što je obično slučaj kod lizičkih lica i manjih 
pravnih subjekata, dok se kod ostalih pravnih lica taj deo ne izvršava ručno. Ti procesi 
mogu biti podržani mnogim na tržištu prisutnim ekvivalentnim proizvodima. Oni su 
ekvivalentni jer im u odnosu na isti skup zadatih transakcija mora biti, kao izlaz, isti 
skup platnih poruka. 

Proces 1.1.2. Payment realization sastoji se od standardnih proceduralnih procesa, kao 
što su vcriiikacija informacija za plaćanje, priprema platne poruke, interakcija sa 
platnim sistemom poređenje poruke sa odgovorom na nju, verifikacija plaćanja koji su u 
odnosu na sistem poruka isto tako ekvivalentni jer im ulazi i izlazi moraju biti isti. Ulazi 
u proces moraju da budu isti jer konačan rezultat jeste standardna poruka koja sadrži 
tačno determinisane informacije u sebi, a izlaz je sama ta poruka koja bez obzira na 
vrstu komponenata koje je proizvode mora biti ista. Interesantna je i fenomenologija 
[167], [168] procesa 1.1.1, za koji može da se pokaže da ima analogone sa RTGS 
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sistemom, kao i kasnije u procesima 1.2.2. i 2.2.3. i 3.1.3, što može biti predmet nekog 
narednog istraživanja. 



Legenda [28]: 

Retail Systemc sistem „па malo“ 

Payment Preparation: priprema plaćanja 

Provision of payment under agreement: obezbeđivanje plaćanja po ugovoru 

Provision of goods: obezbeđivanje dobara 

Provision of services: obezbeđivanje servisa 

Requirement to move топеу: potreba za angažovanjem sredstava 

Accounting Reporting: izveštavanje knjigovodstva 

Payment Realization: realizacija plaćanje 

Verification of payment information: provera podataka za plaćanje 
Preparing payment message: priprema poruke za plaćanje 
Ineraction with payment services: interakcija sa platnim servisom 
Customer Credit Transfer Initiation: klijentska inicijacija transfera sredstava 
Payment Cancelation Request: zahtev za otkazivanjem plaćanja 
Customer Payment Reversal: povraćaj plaćanja klijentu 
Payment Status Report: izveštaj o statusu plaćanja 

Comparsion Payment message with response: poređenje poruke za plaćanje sa odgovorom 

Verification of Payment: verifikacija plaćanja 

Payment Realization Reporting: izveštavanje o realizaciji plaćanja 


Slika 118. Retail sistem 


Proces 1.2. Bank’s Retail Credit Transfers System započinje proverom inicijalnih 
parametara sistema koje je zadala nadređena institucije i koji mogu da se sastoje od 
promenljivih parametara sistema u odnosu na trenutnu situaciju u čitavom sistemu. Na 
ovaj način se postiže poželjna povratna sprega u sistemu, odnosno upravljačka funkcija 
nadređene institucije, koja je objašnjena u poglavlju 1.1.1. 

Ukoliko ne bi postojao ovaj automatizovani proces, podređena institucija bi bila u prilici 
da ne izvršava svoje zakonskim ili podzakonskim aktima regulisane obaveze i mogla bi 
da ugrozi svoje postojanje. Poređenjem slike 117. i slike 118. možemo uočiti određeni 
broj procesa koji se ponavljaju i koji su po svojoj funkcionalnosti istovetni. U pitanju su 
osnovni procesi Interaction with payment services (1.1.2.3. i 1.2.2.) sa svojim 
podprocesima. 
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Legenda: 

Bank’s Retail Credit Transfer System: sistem banke ,,na malo“ za transfer sredstava 

Contirmation of Initial System Parameters: potvrđivanje inicijalnih sistemskih parametara 

Interaction with Payment Services: interakcija sa platnim servisom 

Payment Document Cheking: provera platnih dokumenata 

Customer Credit Transfer Initiation: inicijacija klijentovog transfera sredstava 

Payment Cancelation Request: zahtev za otkazivanje plaćanja 

Customer Payment Reversal: povraćaj plaćanja klijentu 

Response Managing: upravljanje odgovorom 

Payment Status Report: izveštaj o statusu plaćanja 

Bank’s Retail Credit Transfer ToCore Connection: veza transfera sređstava banke „па malo" i kor sistema 
Bank’s Retail Credit Transfer Monitoring: monitoring transfera sredstava banke „па rnalo" 

Bank’s Retail Credit Transfer Reporting: izveštavanje o transferu sredstava banke „па rnalo” 

Slika 119. Retail Credit Transfers sistem banke 



Legenda: 

Bank’s processor Credit Transfer System: sistem banke za transfer sredstava procesoru 

Contlrmation of Initial System Parameters: potvrda inicijalnih sistemskih parametara 

Payment Document Checking: provera platnih dokumenata 

Customer Credit Transfer: klijentov transfer sredstava 

Payment Cancelation: otkazivanje plaćanja 

Customer Payment Reversal: povraćaj plaćanja klijentu 

Response Managing: upravljanje odgovorom 

Payment Status Report: izveštaj o statusu plaćanja 

Interaction with Clearing Services: interakcija sa servisima kliringa 

Bank’s Processor Credit Transfer ToCore Connecting: veza transfera sredstava kor sistema banke i procesora 
Bank’s Processor Credit Transfer Monitoring: monitoring transfera sredstava banke procesoru 
Bank’s Processor Credit Transfer Reporting: izveštavanje o transferu sredstava banke procesoru 


Slika 120. Credit Transfers sistem procesora banke 
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Legenda: 

Processor’s Neto System: procesorov neto sistem 

Contlrmation of Initial System Parameters: potvrda inicijalnih sistemskih parametara 

Processor Neto Pre-processing: procesorovo neto pretprocesiranje 

Interaction with Core Processing Services: interakcija sa kor servisima procesiranja 

Payment Document Checking: provera platnih dokumenata 

Customer Credit Transfer: klijentov transfer sredstava 

Payment Cancelation: otkazivanje plaćanja 

Customer Payment Reversal: povraćaj plaćanja klijentu 

Response Managing: upravljanje odgovorom 

Payment Status Report: izveštaj o statusu plaćanja 

Processor Credit Transfer Monitoring: procesorov monitoring transfera sredstava 
Processor Credit Transfer Reporting: procesorovo izveštavanje o transferu sredstava 


Slika 121. Procesorov neto sistem 



Legenda: 

Processor’s Bruto System: procesorov bruto sistem 

Confirmation of Initial System Parameters: potvrda inicijalnih sistemskih parametara 

Interaction with Processor Neto Services: interakcija sa procesorovim neto servisima 

Interaction with Bruto Services: interakcija sa bruto servisima 

Payment Document Checking: provera platnih dokumenata 

Payment Transfer: transfer plaćanja 

Payment Cancelation: otkazivanje plaćanja 

Customer payment Reversal: povraćaj plaćanja klijentu 

Response Managing: upravljanje odgovorom 

Payment Status Report: izveštaj o statusu plaćanja 

Processor Bruto System Monitoring: monitoring procesorovog bmto sistema 
Processor Bruto System Reporting: izveštavanje o procesorovom bmto sistemu 


Slika 122. Procesorov bruto sistem 

Poređenjem slika 119, 120, 121 i 122. možemo takođe uočiti procese na nivou banke, 
procesora i bruto sistema, koji se ponavljaju i koji su po svojoj funkcionalnosti potpuno 
isti. Proces Confirmation of Initial System parameters je na svim nivoima isti. 
Interakcija sa nadređenim sistemom takođe, ali procesi na različitim nivoima imaju 
različite nazive jer se naredni sistem sa kojim je u interakciji drugačije naziva. U pitanju 
su sledeći procesi: 2.1.2. Interaction with Clearing Services, 2.2.3. Interaction with 
Core Procesing Services i 3.1.3 Interaction with Bruto Services. Isti slučaj je i sa 
procesima monitoringa na različitim nivoima: 2.1.4., 2.2.4. i 3.1.4. Takva situacija je i 
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sa procesima za reporting: 2.1.5, 2.2.5, i 3.1.5. Procesi interakcije (2.1.2, 2.2.3. i 3.1.3.) 
na svim nivoima imaju istu strukturu. 

Generalizacija prva dva nivoa: Na osnovu razmatranja u prethodnom poglavlju i 
uzevši u obzir da za svaku transakciju, bez obzira na vrstu, postoji inicijacija, kliring i 
na kraju poravnanje, može se izvršiti generalizacija, po vrsti transakcija koje se 
procesiraju, odnosno po instrumentu plaćanja koji se koristi, kao što je to prikazano na 
slici 123. Dakle, bez obzira koji se instrument plaćanja koristio ( Credit Transfers, 
direktno zaduženje, kartice) sled procesa i njihov odnos bio bi isti. 



Legenda: 

Payment System: platni sistem 

tnitiation: inicijacija 

Retail System: sistema „па malo" 

Bank’s Retail System: sistem banke „па malo“ 

Reporting: izveštavanje 

Clearing & Settlement: kliring i poravnanje 

Bank’s Processor System: sistem banke ka procesoru 

Processor’s System: procesorov sistem 

Reporting: izveštavanje 

RTGS Settlement: RTGS poravnanje 

Processor’s Bruto System: procesorov bruto sistem 

RTGS Reporting: RTGS izveštavanje 

Slika 123. Generalizacija prva dva nivoa 

Mogućnost generalizacije po dubini procesa, odnosno po definisanim nivoima 
elektronskog poslovanja platnih sistema, može se pokazati na primeru kredit trasfer 
procesa jedinstvene evropske platne zone (SEPA Credit Transfers). SEPA Credit 
Transfers Scheme RuleBook determiniše kontekst i prostor u kome se odvijaju servisi 
koji obezbeđuju Credit Transfers procese. Prostor se u prvom redu specijalizuje na tri 
osnovna: prostor u kome se odvijaju procesi Credit Transfers inicijacijacije, prostor 
neto poravnanja/izvršavanja plaćanja i prostor konačnog bruto poravnanja. Proces 
započinje kompletiranjem i prosleđivanjem Credit Transfers instrukcija od strane 
nalogodavca, nastavlja prihvatanjem instrukcija za neto poravnanje i plaćanje, a 
završava sa bruto poravnanjem učesnika - banaka i prosleđivanjem odgovarajućih 
poruka o realizaciji od sistema za bruto poravnanje pa do učesnika - nalogodavca i 
korisnika. Institucije mogu da budu: deo sistema u banci prema Retail korisnicima - kao 
banka, deo sistema u banci prema procesoru - kao deo sistema od banke prema 
procesoru, procesorov deo sistema prema banci - kao procesorov neto sistem i 
procesorov deo sistema prema sistemu za bruto poravnanje. Struktumom sistem 
analizom može se doći do prostih procesa, a zatim se može izvršiti njihova 
generalizacija. Iz navedenog razmatranja sledi da je savladavanje složenosti platnih 
sistema moguće rešiti upotrebom osobina rekurzije opisane matematički modelom, 
objašnjenim u ovom radu, i po dubini - nivoima sistema. Na taj način se savladava i 
složenost upravljanja platnim sistemom. 
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6.4.2 Saradnja između učesnika 

Mandat predstavlja ugovornu relaciju između poverioca ( Creditor ) i dužnika ( Debtor ), 
kojom dužnik svojim potpisom daje: 1. Poveriocu svoj pristanak i ovlašćuje ga da 
inicira transakcije direktnog zaduženja (direct debit transakcije) koje će rezultirati 
zaduženjem dužnikovog računa, a sve u skladu sa pravilima definisanim SEPA Direct 
Debit Scheme Rulebook-om i detaljima potpisanog Mandata; 2. Banci dužnika svoj 
pristanak da deluje po takvim instrukcijama, a sve u skladu sa pravilima definisanim 
SEPA DirectDebit Scheme Rulebook-om. 

Analizom mandata za SEPA Direct Debit, odnosno ugovora, može se doći do rezultata 
koji imaju eksplicitan uticaj i na sve ostale mandate koji se sklapaju u platnom sistemu i 
za ostale procese. 

Osnovna forma postojanja mandata koju predviđa Europen Pavment Concil - EPC jeste 
papirni dokument, koji je fizički potpisan od strane dužnika. SEPA Direct Debit Scheme 
Ruiebook-om EPC predvideo je i postojanje mandata u elektronskoj formi, pri čemu 
dokument koji predstavlja mandat mora biti kreiran i potpisan na siguran način. Bez 
obzira u kojoj je formi, mandat mora da sadrži obavezan pravni tekst, kao i imena strana 
koje su potpisnice mandata. 

Sam proces uspostavljanja mandata može otpočeti nakon registracije poverioca i pre 
upućivanja prve transakcije za direktno zaduženje (Direct Debit Collection). Inicijativa 
za uspostavljanje mandata može biti pokrenuta od obe zainteresovane strane, poverioca 
ili dužnika. Poverilac može da ponudi dužniku mogućnost popunjavanja mandata 
elektronskim putem, uključujući pritom i obezbeđivanje elektronskog potpisivanja 
mandata zbog osobine neporecivosti elektronskog dokumenta. Pravila koja se odnose na 
uspostavljanje mandata elektronskim putem specificirana su u SEPA Direct Debit 
Rulebooku. 

EPC je početkom 2007. godine utvrdio da regulativa postupaka sa mandatima [146] nije 
na odgovarajući način uspostavljana [71], [67]. Zbog toga je početak korišćenja 
instrumenta plaćanja Direct Debit odložen. Već sa slike 124. gde je predstavljeno 
uspostavljanje mandata, vidljivo je da ne postoji regulativa koja bi ponovno uspostavila 
odnose između učesnika ukoliko bi elektronski mandati bili kompromitovani. Zaključak 
je izveden iz opšteg postupanja sa dokumentima u papimom obliku, gde postoji 
nezavisna treća institucija koja služi za skladištenje originala koji bi u slučaju spora bio 
dokaz (u Srbiji su to sudovi gde se skladište originali potpisanih ugovora) i postupanja u 
slučaju elektronskih dokumenata koji imaju relativno mali životni vek zbog mogućnosti 
razbijanja potpisa i nemogućnosti poređenja jer ne postoji institucija koja bi skladištila 
elektronski potpisane originale koji bi se koristili u slučaju spora. Dedukcijom se može 
pokazati da i dmge ugovore između učesnika prati ista problematika, i u papimom i 
elektronskom obliku, i da bi se, ukoliko se reši problem za jedan slučaj, on mogao 
koristiti i za ostale. Na taj način bi se mogle regulisati i sve vrste ugovora između banke 
i klijenta, banke i procesorske kuće i slično. To bi bila mogućnost za redefinisanje 
poslovnih procesa koji su sada uobičajeni, uvođenje novih servisa i bankarskih 
proizvoda. Komponenta ili podsistem za poslovni proces upravljanja mandatima bila bi 
standardna. 
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Legenda: 


Creditor: dužnik 

Creditor Bank: dužnikova banka 

Clearing and Settlement: kliring i poravnanje 

Deptor Bank: poveriočeva banka 

Deptor: poverilac 

Archiving and Dematerialisation: arhiviranje i dematerijalizacija 

Send Mandate with each Instruction: slanje mandata sa svakom instrukcijom 

AOS: dodatni opcioni servisi (Additional Option Services) 

Issuing of Paper Mandate: izdavanje papimog ugovora 
Electronic Mandate: elektronski ugovor 


Slika 124. EPC: Uspostavljanje mandata 

6.4.3 Specifikacija sistema za razmenu poruka 

Realizacija platnog sistema nije karakteristična samo za platne sisteme jer i ostali 
Message Oriented Svstems (MOS) imaju iste fenomenološke elemente [52]: 

• postoji potreba za velikim obimom razmene poruka; 

• postoji struktura podređenih i nadređenih sistema sa supersistemom, 

• postoje veze sa drugim MOS; 

• akvizicija poruka se vrši sa veoma širokog geografskog područja; 

• distribucija poruka se vrši na veoma široko geografsko područje; 

• akvizicija i distribucija se vrše kroz zadate institucionalizovane nivoe 
odgovomosti; 

• poruke za razmenu informacija o poslu standardizovane su od strane institucija 
za globalnu standardizaciju; 

• poruke za razmenu informacija sadrže informacije za adresiranje i procesiranje; 

• standardi pomka su bazirani na XML-u; 

• osnovni sklop standardnih elemenata je kao i za platne sisteme, slika 3; 

• gmpisanje konglomerata gradivnih jedinica vrši se kao i za platne sisteme, slika 

4; 

• sisteme međusobno samo razlikuju zadati formati, informacije za procesiranje i 
komponente za konkretno izvršavanje procesiranja. 
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Na osnovu prethodnog i činjenice da je rasprostranjenost MOS u savremenom društvu 
veoma velika, od sistema za platni promet, pa do sistema za SMS mobilnu naplatu 
parkiranja u velikim gradovima, priloženi radni model sistema pokazuje da je moguće 
izgraditi savremen i moderan sistem koji bi zadovoljio sve potrebne zahteve [233]. 

Bus je podsistem koji se koristi za transfer podataka između aplikativnih komponenata 
u jednom računarskom sistemu ili između aplikativnih komponenata različitih 
računarskih sistema. Razmena poruka korišćenjem Message Bus -a vrši se na pouzdan 
način uz pomoć različitih i prilagodljivih formata poruka. Prenos može biti i asinhron i 
to je rešenje u situaciji kada distribuirani sistemi nisu u mogućnosti uvek da budu 
dostupni. Enterprise Service Bus (ESB) predstavlja okruženje sačinjeno da unapredi 
sofisticiranu povezanost između servisa. Ono ustanovljava međusloj za 
pretprocesiranje, koje pomaže da se prevaziđe određen skup problema povezanih sa 
pouzdanošću, skalabilnošću i nejednakošću po pitanju komunikacionih mogućnosti. 
ESB je sačinjen od niza uzoraka kao što su: asinhroni red čekanja, posrednik servisa 
(transformacija modela podataka, transformacija formata podataka, premošćavanje 
protokola), rutiranje, pouzdan prenos poruka, centralizacija polisa, centralizacija pravila 
i prenos poruka iniciranih događajima. Razmena potrebnih informacija između 
navedenih učesnika, odnosno integracija platnih sistema putem poruka korišćenjem 
odgovarajućih protokola bezbedna je , pouzdana, i u potpunosti zadovoljava potrebe 
takvih sistema. Dugi niz godina na taj način se vrši razmena poruka na taj način u 
finansijskoj industriji. Uočeni su sistemi baziranih na standardnim adresibilnim 
porukama u globalnom platnom sistemu na različitim organizacionim nivoima koji se 
mogu integrisati upotrebom jednog ili više sistema za razmenu poruka. 

Glavni razlog postojanja transportnih sistema poruka jeste smanjenje kompleksnosti 
veza između aplikativnih sistema. 

Svaki finansijski sistem se sastoji od sledećih učesnika: 

• supersistema - nadređenog centra; 

• procesorskog sistema nad kojima supersistem ima nadležnost; 

• strukture mreža subordinate sistema - učesnika u ,,saobraćaju“. 

Svaki od učesnika poseduje jednoznačne instance elektronskih dokumenata koji su 
učestvovali ili koji će učestvovati u poslovnim procesima. Jedan od poslovnih procesa 
je i prenos elektronskih poruka, odnosno elektronskih dokumenata, od jednog učesnika 
do drugog uz pomoć aplikativnog srednjeg sloja. Nad elektronskim dokumentima 
vlasništvo imaju supersistem [131] (podaci upravnog centra i podaci o procesiranju u 
procesorskom sistemu), procesorski sistem (podaci procesorskog sistema i podaci o 
procesiranju poruka subordinate sistema) i podaci subordinate sistema. Nabrojane 
grupe podataka čine jedinstvenu celinu. Moraju da se čuvaju zadati vremenski period. U 
slučaju nedostatka, na bilo kom nivou, nekog elektronskog dokumenta (ili skupa 
elektronskih dokumenata) dolazi do ozbiljnog narušavanja elemenata finansijskog 
sistema koji se balansiraju pravnom i kaznenom regulativom. Neposedovanje 
elektronskih dokumenata, njihovo uništavanje ili nehatno rukovanje u većini slučajeva 
predstavlja ozbiljan krivični akt. Postoji mnogo različitih načina da se poruka prenese sa 
jedne lokacije na drugu. Jedan od načina je i korišćenje SWIFT servisne mreže koja je 
namenjena za takvu vrstu poslova. Dugi niz godina SWIFT je imao monopol u ovoj 
oblasti, ali razvojem informacionih tehnologija postalo je moguće izgraditi isti takav 


Slobodan Babić \ Fakidtet organizacionih nauka 


238 



Doktorska disertacija: Model interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama 


sistem od strane nezavisnih institucija i kompanija i na taj naćin omogućiti nezavisnost 
platnih sistema od SWIFT organizacije. Platni sistemi ranijih generacija imali su svoje 
načine za transport, koji su bili slabih perfonnansi i jedva zadovoljavali potrebe za 
razmenom poruka. Primer za to je RTGS sistem u NBR Makedoniji, koji je početkom 
2000. godine radio sa ograničenjem - 3000 poruka na dan. U naredna dva poglavlja 
prikazana su dva savremena sistema za razmenu platnih poruka. 

Saga SEP transportni sistem 

Saga SEP transportni sistem [166] je baziran na Windows Communication Framework- 
u. WCF je Microsofl-ovo okruženje (framework ) za razvoj zaštićenih, pouzdanih, 
transakcionih i interoperabilnih distribuiranih aplikacija. WCF inkorporira programski 
model koji koristi „kontrolisani” kod za razvoj unificiranih WEB servisa i drugih 
distribuiranih sistema koji mogu međusobno komunicirati. WCF se fokusira na 
povezivanje XML sa programima razvijenim pod Microsoft podržanim razvojnim 
jezicima VB.NET i C#. Da bi podržao tu međujezičku komunikaciju, WCF koristi 
Extensible Simple Object Access Protocol (SOAP). 

Servisno orijentisana arhitektura [69] Saga SEP transportnog sistema je u suštini skup 
servisa koji komuniciraju jedni sa drugima i mogu uključiti prostu primopredaju 
podataka, ali i uključiti dva ili više povezanih servisa da bi se izvršila neka aktivnost. 
Slika 125. prikazuje osnovu servisno orjentisane arhitekture. Korisnik servisa šalje 
zahtev isporučiocu servisa. Na taj zahtev isporučilac servisa vraća adekvatan odgovor 
korisniku servisa. Zahtev i odgovarajući odgovor se ostvaruju preko konekcije koja je 
na neki način detenninisana i koju obe strane mogu da razumeju. Interesantno je da 
isporučilac servisa može da bude i korisnik servisa. 


Isporučilac ч- 
servisa _ 


Zahtev za servis 



Odgovor na zahtev 


Konekcija 

Korisnik 

servisa 


Slika 125. Osnova servisno orijentisane arhitekture 

Saga SEP transportni sistem je projektovan da obezbedi sigumu, dostupnu i efikasnu 
razmenu pomka, baziranih na SWIFT-u i drugim industrijskim standardima između 
učesnika u sistemu. Sistem može da bude zamena sa vlasničkom (jeftinijom) mrežom za 
saobraćaj koji se odvija putem SWIFT mreže. Sistem je implementiran u Udmženju 
banaka Srbije - Klirinškoj instituciji banaka [214], [13] (UBS KIB) i OTP banka Srbije. 

Sistem je modularan, dostupan, stabilan, skalabilan, sa odgovarajućim bezbednosnim 
mehanizmima i sa visokim performansama. Baziran je na Microsoft tehnologijama i one 
minimizuju operativni rizik od korišćenih tehnologija pošto su svi ostali sistemi u klasi 
realizovani drugim tehnologijama koje nisu bazirane na Microsoft proizvodima. Pred 
sistem su postavljeni i zahtevi koji se odnose na njegovu šim upotrebnu vrednost, u 
smislu: 


mogućnosti transparentnog korišćenja nezavisno od geopolitičke ili bilo koje 
druge konfiguracije učesnika; 

neograničavanja samo na domene finansijske industrije; 
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mogućnosti da budu uključeni i srodni procesi podržani prihvaćenim standardom 
za specifikaciju poruka; 

da se mogu podržati i svi ostali sistemi bazirani na komunikaciji i razmeni 
standardnih poruka koje u sebi sadrže informacije o adresi primaoca i 
poslovnom procesu koji treba da se obavi na lokaciji prijema. 

Tabela 20. prikazuje uobičajene projektne zahteve koji se postavljaju pred jedan ovakav 
sistem i opis na koji način su oni ispunjeni u rešenju implementiranom u UBS KIB-u. 


R.br. 

Projektni zahtev 

Opis ispunjenih zahteva 

1 . 

Dostupnost 

24 časa х 7 dana u nedelji 

2. 

Bezbednost 

Sigumost bazirana na upotrebi sertifikata javnih ključeva (Microsoft Enterprise 
CA sa infrastmkturom javnih ključeva - PKI) 

3. 

Performanse 

Testiran na 500k transakcija na sat (frame relay 512k) 

4. 

Stabilnost 

Verzija 1.0 prve godine rada imala “zero down time” 

5. 

Modularanost 

Mogu se dodavati moduli opšte i specijalne namene u slučaju proširenja seta 
funkcionalnih zahteva, na primer za dostavu pomka sistemu za procesiranje 
pomka direct debita, prinudne naplate, kliringa naloga ili nekog drugog 
sistema za procesiranje. 

6. 

Skalabilnost 

U slučaju potrebe, radi proširenja kapaciteta, može se dodati odgovarajući broj 
hardverskih komponenata 


Tabela 20. Osnovni projektni zahtevi i njihova ispunjenost 
Saga SEP transportni sistem omogućava: 

a. ) širok opseg slobode definisanja pristupnih kanala; 

b. ) različite vrste procesiranja; 

c. ) dodavanje proizvoljnih programskih biblioteka posebne i opšte namene; 

d. ) mogućnost dcfinisanja arhitekture koja je po teorijskim standardima na 
visokom mestu; 

e. ) uvođenje vrlo širokog spektra konfiguracionih parametara za detenninisanje 
sistema u cilju postizanja vrlo jake povratne sprege sa mogućom promenljivom 
okolinom sistema; 

f. ) slobodom definisanja komunikacije sa zahtevanim ekstemim sistemima 
putem primopredaje servisa; 

g. ) definisanja proizvoljnog workflow mehanizma; 

h. ) mogućnost reakcije na podražaje bilo unutar sistema ili van njega planiranim 
događajima iz nekog izvora. 

Funkcionalnosti koje sistem ispunjava su sledeće: 

1. transport SWIFT poruka i ostalih definisanih standardnih dokumenata; 

2. razmena poruka putem sistema foldera, MSMQ ili putem odgovarajućih 
aplikativnih adaptera; 

3. predvalidacija poruka (prva tri bloka SWIFT poruke); 

4. digitalno potpisivanje svake poruke i provera potpisa na ishodištu; 

5. pet modova transporta (sinhrono - asinhrona kombinacija sa predajnikom i 
prijemnikom i odgovarajućom potvrdom prijema - ACK / NAK), kao i fire 
& forget mehanizam (streaming mode); 

6. rutiranje poruka kroz predefinisane rute; 

7. arhiviranje poruka; 

8. postojanje aplikativnih komponenti za monitoring predaje/prijema. 
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Navedene funkcionalnosti sistema izdvojene su kao najkarakterističnije i 
najinteresantnije u odnosu na tehnologije finansijske industrije. 

Sistem je nezavisan od komunikacione infrastrukture. Postoje primeri iz prakse 
(prouzrokovani elementamom nepogodom) gde je komunikacija obavljana sa mobilnih 
uređaja bez ikakvog dodatnog obaveštavanja ostalih učesnika o izmeni fizičkog načina 
obavljanja komunikacije. Jedini zahtev za komunikaciju je da su učesnici URL 
adresibilni. Moguća je integracija u sve poznate sisteme za razmenu pomka. 

Bezbednost je bazirana na PKI infrastmkturi. To daje garanciju da će svaka pomka stići 
neizmenjena i sa dokazom o poreklu. Postoji opcija koja kriptuje kanale za 
komunikaciju. PKI infrastmktura je podržana od strane Microsoft CA servera. 

Projektovani koncepti su verifikovani u Microsoft Technology Center (EMEA) u 
Kopenhagenu u Danskoj marta 2005. Testiranje u Microsoft Tehnologv centm je 
ugovoreno i ima za cilj da dokaže da je Transportni sistem v3.0 sposoban da zadovolji 
potrebe za prenosom dokumenata za procesiranje i najvećih zemalja kao što su EU, 
Rusija, Brazil, Kina, Indija ili Sjedinjene Američke Države. 

Sistem je baziran na WCF arhitekturi i prikazan na slici 126. Osnovna odlika ove 
arhitekture jeste kompozibilnost (nadgradivost). Ova arhitektura omogućava 
inkrementalan razvoj veb-servisa kroz pojedinačne zahteve (sigumost, pouzdanost, 
pridmživanje paketa - attachments, filtriranje). Svaki od ovih zahteva rešava se 
izolovano od dmgih, što znatno pojednostavljuje razvoj. Konkretna implementacija 
realizuje BUS arhitektum. Servis bus reprezentuje logičku konekciju međusobno 
povezanih sistema. Istovremeno omogućava razdvajanje nivoa poslovne logike od 
komunikacionog nivoa. Osnovne odlike sistema su: 

1. potpuna konfigurabilnost sistema (Configuration procesor ); 

2. servisi bazirani na WCF tehnologiji; 

3. servis loader and manager, 

4. inicijalan set procesora pomka (message sender, receiver ); 

5. ugrađen sistem za automatsko arhiviranje pomka; 

6. store manager; 

7. konfigurabilni servis preprocesori, postprocesori i filteri; 

8. konfigurabilni servis adapteri; 

9. jednostavno proširenje funkcionalnosti (dodavanje novih servisa); 

10. ugrađeni security mehanizmi. 



Slika 126. Arhitektura eMessaging Transport System Service BUS-a [166] 
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U okviru servisa za prijem i slanje poruka realizovani su sledeći načini prijema poruka: 
sinhroni prijem, asinhroni prijem, Fire & Forget (prijem bez odgovora). Fizički kanali / 
protokoli za prenos podataka definišu se preko konfiguracije, tj. procesori poruka su 
apsolutno nezavisni od protokola komunikacije. Sistem je testiran na sledeće protokole 
prenosa podataka: HTTP, HTTPS (SSL), TCP/IP, MSMQ, Message PIPE. 

Realizovani sistem konzistentno primenjuje WCF securitv mehanizme koji obuhvataju: 
message layer securitv za autentifikaciju poruka, transport layer securitv za 
poverljivost, upotreba X509v3 sertifikata kao security tokena, direct / brokered 
autentikaciju. Na aplikativnom nivou primenjuje se dodatna zaštita kao na primer: 
kriptološka zaštita sadržaja, međusobna autentikacija krajnjih učesnika. 

OpenAMO 

Osnovni podaci OpenAMQ sistema iMatix korporacije: 

• Proizvođač 

■ iMatix korporacija 

• Zasnovanost na besplatnom softveru 

■ GNU besplatni alati i programski jezici, model-oriented 
programming (MOP) alati iMatix korporacije i jezici iMatix 
korporacije 

• Tekuća verzija softvera 

■ 1.2c4. (15.10.2007.) 

• Broj verzija OpenAMQ realizovanih i testiranih pre verzije l.OdO: 

■ 55 

• Prva linija koda napisana: 

■ 02.10.2004. 

• Veličina upoterbljene iMatix tehnologije: 

■ 524,133 linija C/C++koda 

• Veličina OpenAMQ osnovnog proizvoda: 

■ 309,656 linija C/C++ koda, 10,537 linija MOP koda 

• Procenat OpenAMQ koji je generisan iz modela: 

■ 99.79% 

• Najveća brzina zabeležena na jednoprocesorskoj mašini: 

■ 40,000 poruka/sekundi (poruke od 500 bajta) 

• Najveća brzina zabeležena na višeprocesorskoj mašini: 

■ 140,000 poruka/sekundi (poruke od 500 bajta) 

• Teorijski limit na gigabitskoj mreži: 

■ 512,000 poruka/sekundi (poruke od 500 bajta) 

• Prvi dan produkcije sa transportom podataka kroz OpenAMQ : 

■ 09.05.2006 (JPMorganChase) 

• Maksimalni broj poruka u toku dana po jednoj aplikaciji: 

■ 100,000,000 (JPMorganChase) 

Samo 0.21% OpenAMQ od 310k linija C koda je pisano rukom. Ostatak je generisan iz 
modela, korišćenjem iMatix Model Oriented Programming (MOP). MOP prevodi XML 
modele visokog nivoa u izvršni kod. Modeli koji su korišćeni su sledeći: state 
machines, class systems, grammars i metamodele. Umetanjem jednog modela u drugi, 
dobijaju se modeli koji su sposobni za pravljenje novih modela koji proizvode 
odgovarajući izvršni kod koji ima veoma mali procenat grešaka sa izuzetno malim 
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konvencionalnim troškovima izrade. OpenAMQ je oslonjen na nekoliko tehnoloških 
nivoa od kojih je najviši ASL Abstract Server Language. ASL je alat koji je izgrađen 
specijalno da prihvati AMQP gramatiku ( Advanced Message Queue ProtocoT) i 
automatski je preobraćuje u okruženja za izradu klijenata i servera. Uzimajući 
odgovarajući AMQP protokol ispisan kao ASL model, u nekoliko sekundi dobija se 
potpuna izvršna verzija klijenta, fremwork za server, veliki deo potrebne 
dokumentacije. 

Glavne osobine OpenAMQ sistema su: 

• ekonomičnost (jeftina ili besplatna licenca moguće ga je izvršavati na 
proizvoljnom operativnom sistemu, prosta instalacija i konliguracija, jeftina 
administracija, prost interfejs); 

• dostupnost svim korisnicima (iziskuje male troškove, kompatibilan sa 
aplikativnim sistemima na bilo kom jeziku i bilo kojoj tehnologiji, ne zauzima 
puno resursa i pogodan je za uređaje ograničenog kapaciteta); 

• koristnost (koristi se za rešavanje svakodnevnih problema u korporacijskim 
sistemima korišćenjem store and forward, publish - subscribe, multicasting i 
ostalih messaging mehanizama); 

• kvalitet servisa (prihvata veliku količinu poruka ograničenu samo lokalnim fajl 
sistemima, može da garantuje maksimalno vreme isporuke za speciiičnc servise, 
može da garantuje minimalni propusni opseg za specifične servise, može da 
rukuje sa greškama na praktičan način); 

• sofisticiranost (može da se prihvati i složenih zadataka kao što je rutiranje 
poruke po adresi primaoca, sadržaju, izračunatoj vrednosti, individualnoj 
aplikaciji, grupi aplikacija, privremenim ili stalnim nadimcima, jedinicama u 
okviru grupe i slično, radi nad više virtuelnih mreža nad jednom fizičkom 
mrežom, recimo razvojno, produkciono i testno okruženje, dozvoljava enkripciju 
i potpisivanje sadržaja kada je to potrebno); 

• može da pobudi proces koji je zadužen za prihvatanje određenih podataka; 

• može da se integriše sa workflow sistemima. 

OpenAMQ podržava različite messeging arhitekture: 

• Store-and-forward sa više čitača i pisača; 

• distribuciju transakcija sa više čitača i pisača; 

• publish-subscribe sa više čitača i pisača; 

• rutiranje bazirano na sadržaju sa više čitača i pisača; 

• transfer fajlova uz pomoć reda za čekanje sa više čitača i pisača; 

• point-to-point veze između dva izvora; 

• distribuciju marketinških podataka sa više izvora i mnogo čitača. 

Kod OpenAMQ sistema pretpostavka je da klijenti mogu da adresiraju server direktno. 
Serveri ne mogu da adresiraju klijente. 

Iz analize osnovnih funkcionalnih oblasti slede sledeći podržani varijeteti: 

• veličina poruke može da varira od veoma malih do veoma velikih; 
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• poruka može da sadrži aplikativne podatke, fajlove, i druge sadržaje kao što su 
kontinualni podaci - strimovi; 

• zahtev za dostupnost, od veoma niske do veoma visoke dostupnosti; 

• zahtev za vremenom potrebnim za pobuđivanje u opsegu od nevažno do 
kritično; 

• model za rutiranje može da podrži više različitih načina kao što su primalac sa 
jednim imenom, rutiranje bazirano na sadržaju i drugi; 

• modeli distribucije podataka na više različitih načina. 

Poređenje sistema za transport poruka 

Saga SEP transportni sistem i OpenAMQ sistem svakako su dva veoma različita 
proizvoda bazirana na drastično različitim tehnologijama. Međutim, njihove funkcije su 
potpuno iste, i u izgradnji platnog sistema bismo mogli bi se ravnopravno koristiti i 
jedan i drugi jer su Saga SEP transportni sistem i OpenAMQ anološki isti. Možemo 
primetiti da je i način na koji se sistemi realizuju veoma različit: dok se OpenAMQ, u 
viskom procentu, dobija generisanjem iz modela, dotle Saga SEP koristi Windows 
Communication Framework sa odgovarajućim funkcijama i na takav, vrlo lak način 
dostiže visoku složenost i upotrebnu vrednost sistema. 

6.4.4 Primena ontologija u analizi 

Ontološki domenski model pokazuje da je struktura stabilna, da, ukoliko se uvodi nova 
verzija objekta, u modelu perzistiraju i sve prethodne verzije, a samo poslovna pravila 
determinišu koji objekti su važeći u sistemu. Generički model koristi činjenicu da su 
objekti ne samo ,,stabilni“ u jednom konkretnom sistemu (stabilni u smislu da se bitnije 
ne menjaju čak i kada se funkcije sistema i zahtevi za infonnacijama u sistemu 
menjaju), već i u čitavoj klasi srodnih sistema [189]. Domenska ontologija [43] 
pokazuje da je čitav skup objekata visokog nivoa apstrakcije (generičkih objekata 
derivacijom iz REA Resursa ) isti u različitim poslovnim sistemima, pa oni treba da 
posluže kao osnova za razvoj modela podataka i ponašanja (procesa - derivacijom iz 
REA Event- a). 

Sa druge strane (Slika 127.), u skupu objekata poslovnog sistema postoji skup 
nezavisnih objekata (objekata koji pripadaju nivou poslovnog subjekta u sistemu 
elektronskog poslovanja platnih sistema ili REA Agenata ), čije postojanje nije 
uslovljeno postojanjem nekog drugog objekata u sistemu. Tipovi takvih objekata se 
mogu tretirati kao nezavisno promenljive koordinatne ose, a njihova pojavljivanja kao 
tačke na tim osama, jednog apstraktnog n-dimenzionog prostora koga nazivamo 
apstraktni prostor poslovanja [211]. Pri tome smatra se da je pojavljivanje nekog 
objekta predstavljeno njegovim ključem (ili, još bolje surogatom ključa, identifikatorom 
koga dodeljuje sistem kad god se neko novo pojavljivanje kreira), a atributi ovih 
objekata su funkcije definisane u odgovarajućim tačkama posmatrane koordinatne ose. 
Očigledno je da pojavljivanja agregacija, koje se predstavljaju Dekartovim proizvodom 
tipova (skupova) objekata, određuju tačke u prostoru poslovanja (van koordinatnih osa) 
u kojima su definisane neke druge funkcije - atributi agregacija. 

Domenska ontologija pokazuje da bazni atributi, atributi koji se ne mogu izvesti iz 
drugih atributa u sistemu, predstavljaju samo jedan skup informacija preko kojih se prati 
ponašanje poslovnog sistema. Iz njih se različitim obradama podataka mogu izvesti i 
mnoge druge. Osim izvođenja koja se mogu vršiti nad skupovima ili podskupovima 
pojavljivanja osnovnih objekata i agregacija, veze između objekata u modelu definišu 
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ostale tačke u poslovnom prostoru u kojima se ovakva izvođenja mogu vršiti, a sami 
algoritmi obrade funkcije izvođenja. 
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Legenda 


El, E2,..., En - objekti sistema 
AGl, AG2 - agregacije objekata 
VI, VI - veze objekata 

ALG.IZV - algoritam izvođenja poslovne funkcije 
BAZNI - osnovni objekti 
IZVEDENI - izvedeni objekti 
S - specijalizacija 


Slika 127. Generički model EPPS 

Imajući u vidu apstraktni model i neke generičke objekte poslovnih sistema, razvoj 
modela elektronskog poslovanja platnih sistema zasnovanog na ontologijama odvija se 
kroz: 

• izbor generičkih objekata; 

• rasčlanu generičkih objekata; 

• specij alizacij a, generisanj e hij erarhij e podtipova; 

o definisanje strukture objekata; 
o definisanje baznih atributa objekata; 
o definisanje osnovnih agregacija i njihova rasčlana; 

• definisanje veza između osnovnih objekata i agregacija; 

• analiza funkcija sistema (poslovnih procesa) sa ciljem da se otkriju dodatni 
objekti, agregacije, atributi i veze izvođenja, odnosno da se izvrši dalja rasčlana 
sistema. 

Ovakav pristup je omogućio da se na specifičan, strukturiran način izvede i analiza 
poslovnih procesa, kao i odnosa poslovnih procesa i objekata (klasa podataka), na 
osnovu čega je određena opšta arhitektura informacionog sistema. Naime, agregacije 
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objekata relativno visokog nivoa generalizacije predstavljaju složene objekte koji su 
glavni objekti posmatranja u sistemu elektronskog poslovanja platnih sistema [119]. 

6.4.5 Obezbeđenje interoperabilnosti 

Interoperabilnost je i preduslov i olakšavajući faktor elektronskog poslovanja platnih 
sistema za efikasno pružanje usluga, kojim se rešava potreba za: 

• saradnjom između platnih sistema i ostalih finansijskih institucija, kao i pravnih 
i fizičkih lica na nacionalnom i međunarodnom nivou; 

• razmenom informacija radi ispunjenja poslovnih obaveza ili zakonskih uslova; 

• razmenom i ponovnom upotrebom informacija radi povećanja efikasnosti i 
smanjenja opterećenja na finansijske institucije, pravna i fizička lica. 

Okvir interoperabilnosti je definisan nad skupom standarda finansijske industrije i 
smemica centralne banke koji opisuju način na koji finansijske organizacije, pravna i 
fizička lica moraju uzajamno poslovati. Jednom ustanovljena, interoperabilnost se 
vremenom, izmenom standarda usklađuje i prilagođava promenama zakonske 
regulative, tehnologija, standarda i administrativnih zahteva [64], [63]. 

Referentni izvor za područje interoperabilnosti u finansijskoj industriji jeste svakako 
dokument IS020022 1-5: 2004, standard koji ima kao jedan cilj i konvergenciju svih 
standarda platnih sistema ka jedinstvenom koji će obezbediti olakšanu implementaciju i 
interakciju svih sistema elektronskog poslovanja platnih sistema. 

Narodna banka Srbije, Udruženje banaka Srbije, banke i druge finansijske institucije, 
kao i pravna lica u Srbiji prate prepomke evropskih i svetskih institucija za 
standardizaciju u cilju sinhronizacije sa nacionalnim i svetskim sistemima elektronskog 
poslovanja platnih sistema dmgih evropskih i svetskih zemalja. Iz tog razloga za ovaj 
rad jesu kao osnova relevantnih prepomka osnov uzeti dokumenti IS020022 standarda i 
Evropski okvir interoperabilnosti, kao i modeli koji interoperabilnost i obezbeđuju. 

6.4.6 Rezultati analize 

Logička arhitektura sistema predstavlja stabilnu osnovu za razvoj sistema i omogućava 
sistemu da bude realizovan kao dovoljno fleksibilan kako bi uspešno odgovorio na 
funkcionalne, organizacione, tehnološke i dmge promene u okmženju i samom sistemu. 
Time omogućava ne samo automatizaciju poslovnih procesa, već i njihovo unapređenje. 

Kao što je prikazano na slici 128, sistem je modularan i mapiranjem na odgovarajuće 
fizičke čvorove obezbeđuje se povećanje performansi jednostavnim dodavanjem i/ili 
zamenom komponenata. Ovaj sistem se može funkcionalno podeliti u sledeće celine: 


• komponente poslovne logike; 

o proces Framework; 
o domain Framework; 

• portal, monitoring i administracija; 

• izveštavanje; 

• relacioni sistem za upravljanje bazom podataka; 

• transportni sistem; 
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• adapteri za druge sisteme za razmenu poruka; 

• CA struktura; 

• registraciono telo. 

Kod planiranja razvoja i kreiranja arhitekture sistema pošlo se od osnovnih zahteva koji 
su postavljeni pred projekat, a to su potpuno ispunjenje funkcionalnih zahteva, kao i 
visoka raspoloživost, visoke performanse, pouzdanost i skalabilnost. Sistem je 
zamišljen kao visokodostupan, što podrazumeva operativnu funkcionalnost sistema koja 
je vrlo blizu ili jednaka 100% radnog vremena. U pogledu perfonnansi sistema 
postavljen je zahtev za obradom od minimalno 50.000 dolaznih i 50.000 odlaznih 
poruka na sat, što višestruko prevazilazi trenutne potrebe prosečne procesorske kuće, a 
što je u skladu sa planovima za budućnost procesorske kuće. U pogledu skalabilnosti 
rešen je zahtev da se povećanje kapaciteta/perfonnansi sistema može lako ostvariti 
umnožavanjem postojećih delova sistema (npr. dodavanjem novih servera). 



Slika 128. Logička arhitektura EPPS sistema 

Kao metodologija razvoja sistema može biti izabran Dvmanic Svstem Development 
Method, koji u svojoj osnovi može da prati agilni iterativno-inkrementalni životni ciklus 
razvoja [199]. Ovako delinisana metodologija je kombinovana sa savremenim 
dostignućima u oblasti razvoja kompleksnih IS, prvenstveno u domenu višeslojne 
arhitekture zasnovane na distribuiranim komponentama i servisima. 

Process framework predstavlja komponentu kojom se delinišc funkcije (ponašanje) 
sistema, a realizovana je tako da omogući formalan opis poslovnih procesa. Moguća je i 
promena opisa poslovnog procesa. Mogu se definisati i uslovi koji utiču na tok 
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poslovnog procesa u vreme izvršavanja. Orkestracije se koriste za izvršavanje aktivnosti 
posmatranog procesa. 

Domain framework [32] definišc strukturu sistema. Može biti realizovan kroz sledeće 
komponente: rečnik IS (skladište modela i pravila transformacije), prcdelinisanu 
softversku arhitekturu (dizajn budućih aplikacija) i generator koda (automatizovana 
implementacija transformacija). Na ovaj način omogućeno je da se model koji opisuje 
neki poslovni domen automatizovano transfonniše na odgovarajuću ciljnu platformu. 

Portal, OffLine aplikacija, monitoring i administracija su aplikacije koje omogućavaju 
laku interakciju sa sistemom. Portal aplikacija omogućava adekvatan prijem, odnosno 
ekspediciju dokumenata i njihovo evidentiranje, kao i potrebne procedure za izvršavanje 
zadatih operacija nad dokumentima. OffLine aplikacija omogućava adekvatan prijem, 
odnosno ekspediciju dokumenata i njihovo evidentiranje (slično portal aplikaciji), ali sa 
svim svojim funkcionalnostima determinisanim u odnosu na komunikacioni kanal koji 
je samo povremeno propustan. Real time aplikacija za monitoring omogućava korisniku 
da u realnom vremenu prikazuje zadate setove podataka o stanju sistema koji su u tom 
trenutku za njega bitni. Na pregledan način i lakim izborom detalja (na primer klikom 
miša na određenu oblast) monitoring omogućava da se sagledaju i odgovarajuće 
informacije koje se nalaze raspoređeni hijerarhijski ispod detalja. Administrator sistema 
može da sprovede zahteve izmenom sistema, koji proizilaze iz fu nk cionalnih ili 
aplikativnih razloga preko sistema za administraciju. 

Izveštavanje može biti implementirano korišćenjem Microsoft SQL Server Reporting 
Service-SL. Reporting services dozvoljavaju centralizovano upravljanje, laku proširivost, 
skalabilnost, kao i veliku sigurnost podataka, interaktivne, proaktivne i pasivne izveštaje 
koji se mogu dobiti u više različitih izlaznih fonnata kao što su HTML, EXCEL, WEB 
ARCHIVE, ACROBAT(PDF) FILES, TIFF, CSV, XML fde with report data. Imaju 
ugrađenu podršku za generisanje izveštaja iz velikog broja izvora podataka. Svi izveštaji 
kao i resource fajlovi koji mogu biti postavljeni na report server, organizovani su u 
logičnu hijerarhiju foldera iznad koje je proširivi, na rolama zasnovan securitv sistem 
koji je integrisan sa computer/domain userima i grupama [200]. 

Baza podataka je deo sistema koji treba da omogući visoku dostupnost, pouzdanost i 
visoke performance. Dostupnost se odnosi na procenat vremena u kom je sistem 
dostupan za korisnika. Ona može da se postiže zaštitom sistema od padova, 
obezbeđivanjem redundantnosti sistema u slučaju padova i segmentacijom sistema. SQL 
Server 2012 i Windows 2008 nude više rešenja za ostvarivanje ovih zahteva: Failover 
klastering, Database mirroring, Log shiping, replikacija podataka, SQL Server 
federations. 

Transportni sistem može da bude realizovan kao vlasnička mreža za razmenu poruka. 
Ne postoji ograničenje po pitanju sadržaja; naime, mogu se definisati i drugi sadržaji, 
uključujući i prenos binarnih fajlova između učesnika. Prilikom razmatranja ovog 
sistema treba uzeti u obzir osobine sistema, kao što su brzina implementacije, lakoća 
primene i održavanja rešenja, skalabilnost, bezbednosna infrastruktura zasnovana na 
industrijskim standardima, cross-platform podrška i zadovoljavajuće performanse, kao i 
generalna servisno orijentisana arhitektura sistema, što zavisi isključivo od zahteva za 
instalaciju sistema. 
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6.5 Servisi za procesiranje 

Da bi biro za procesiranje korektno izvršavao dodeljene mu servise, mora se voditi 
računa i o sajtu na rezervnoj lokaciji, rezervnim komunikacionim resursima i sličnim 
aspektima sistema. Servisi procesorske kuće su povezani sa razmenom poruka ili sa 
servisima procesiranja. U nastavku će biti samo nabrojani neki od mogućih najvažnijih 
servisa koje procesorska kuća može da ponudi: rutiranje poruka, notiiikacija prijema 
procesora (ACK/NAK), identifikacija učesnika i njegovo logovanje na sistem, 
autentifikacija učesnika putem kvalifikovanog elektronskog potpisa, prenos 
enkriptovanih podataka, adresiranje sa ograničenjem prijema, verifikacija sintakse, 
verifikacija semantike, verifikacija poslovnih pravila, notifikacija da je poruka 
isporučena primaocu (ACK2/NAK2), skladištenje indentifikacionih i adresnih podataka, 
funkcionalnih i komercijalnih podataka o proizvodima, Veb-servisi prikaza na 
interfejsu, servisi podrške i trajnog arhiviranja poruka. 



Slika 129. Uvođenje novih funkcionalnosti u EPPS sistem 

Fu nk cionalnosti enkripcije poruke ili njenog dela na nivou razmene poruke je veoma 
značajan servis kada učesnik ne želi da bilo ko, bez obzira na ugovorene obaveze 
tajnosti, ima mogućnost da sistematski neovlašćeno prikuplja podatke. Ograničenje 
prijema, takođe, može da se prezentuje kao servis. Podrazumeva izradu baze podataka 
učesnika i tabele ko sa kim može da komunicira. Uvid u ovu bazu, preko odgovarajućeg 
interfejsa, treba da ima sistem za razmenu komponenata i administrativna konzola 
procesora. Notifikacija ACK2 i NAK2 kao servis obaveštava pošiljaoca poruke da je 
primalac poruke fizički primio poruku. Formiranje baze podataka o proizvodima i 
pristup putem veb-interfejsa takođe se može ponuditi kao servis. Pored pretraga 
informacija o proizvodima, kao servis se može ponuditi i pružanje usluga fonniranja i 
čuvanja poruka, pregledanje vezanih sadržaja, eventualno konvertovanje dokumenata, 
slanje dokumenata i drugo. 

Problem uvođenja novih poruka u sistem i njihovo procesiranje u sistemu može da se 
automatizuje i na taj način dogovori životni ciklus elemenata sistema: uvođenje novih 
funkcionalnosti u sistem, izmena starih funkcionalnosti uvođenjem verzija poruka, 
ukidanje funkcionalnosti ukidanjem odgovarajućih poruka u sistemu, slika 129. 


Nadređeni sistem šalje XMF instancu, odnosno poruku sa sadržajem podređenom 
sistemu. Sistem proverava da li je dobijeni fajl XMF instanca, da li je verzija šeme po 
kojoj je kreirana instanca poznata sistemu i vrši ostale potrebne provere, kao na primer, 
da li je instanca od poznatog učesnika, da li je dobar potpis i slično. Ukoliko je već 
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registrovana, odobrena i implementirana šema, odnosno verzija šeme, XML instanca se 
učitava u bazu podataka i izvršavaju se nad njom zadate operacije. Ukoliko nije, traži se 
u instanci po kojoj je šemi kreirana instanca. Šema sa zadatim imenom u instanci 
pronalazi se na zadatoj lokaciji koja je takođe navedena u instanci i odatle se preuzima. 
Na osnovu preuzete šeme generišu se upozorenje administratoru sistema da je stigla 
instanca koja nije podržana u sistemu. Administrator, na osnovu dokumenata o 
uvođenju nove šeme: 

• daje nalog za generisanje baze (aplikacija - pogled na bazu sa pristiglim xsd 
šemama koje nisu odobrene - samo jedno pojavljivanje šeme sa istim 
nazivom); 

• daje nalog za generisanje baze iz XML šeme; 

• po kreiranju šeme daje nalog za kreiranje *.dll-a za učitavanje instanci u 
kreiranu šemu baze podataka (alat ima mogućnost da za generisanu bazu 
sam pronađe podrazumevano - default mapiranje); 

• administrator određuje gde će takva instanca da se učitava (podrazumevanu - 
default šemu za tu instancu) - u aplikaciji ima informaciju da je generisana 
baza i *.dll; 

• odobrava da se učitavaju instance te šeme; 

• učitava sve postojeće instance šeme u bazu za pretprocesiranje; 

• šalje nadređenom sistemu poruku da je izvršeno uspešno prihvatanje nove 
instance za pretprocesiranje. 


Message Name 

Msg ID (XML 
Schema) 

Submitting 

Organisation 

XML Instances 

RequestToModifyPayment 

camt.007.002.01 

SWIFT 


RequestToCancelPayment 

icamt.008 002 01! 

SWIFT 


UnableToApply 

camt.026.001.01 

SWIFT 



Slika 130. camt.008.002.01.xsd shema na IS020022 sajtu sa instancom 

Instance koje pristižu preko sistema za razmenu u ovom trenutku sve mogu da se 
prihvataju na pretprocesiranje. Nakon toga, na osnovu dokumenta o uvođenju nove 
šeme, administrator dodaje odgovarajuće operacije za prihvatanje instance iz sistema za 
pretprocesiranje u sistem za procesiranje i odgovarajuće operacije za prihvatanje 
instance za procesiranje, i šalje nadređenom sistemu poruku da je izvršeno uspešno 
prihvatanje nove instance za procesiranje. Spremišta za procesiranje i operacije moraju 
da budu predefinisana po dokumentima koje je nadređeni sistem prosledio podređenom 
sistemu u procesu uvođenja nove zakonske regulative, novih normativa, pravila ili 
slično. Na ovaj način omogućava se i da proizvoljan broj verzija jedne vrste poruka 
bude u opticaju, što zavisi od učesnika koji zadaje pravila u sistemu. 

U narednom tekstu je opis jednog od načina na koji može da se iskoriste elementi za 
standardizaciju u generisanju elemenata sistema uz pomoć alata koji su prisutni na 
tržištu ili kao open source. Ovo će biti prikazano na jednom opštem primeru koji u sebi 
sadrži sve potrebne elemente da se zaključi da je to moguće i za ostale slučajeve. 

Pođimo od osnovnog materijala - xsd šeme koja se nalazi na IS020022 sajtu. U ovom 
primeru će biti korišćena šema RequestToCancelPayment (camt.008.002.01.xsd) sa 
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svojom odgovarajućom instancom, kao što je prikazano na slici 130. Izgled šeme je 
prikazan u alatu A/fova XMLSpy [3] na slici 131. Alexis Smirnov [192] je pokazao kako 
se unificiraju objekti i relaciona struktura podataka uz pomoć XDS šeme kao osnove 
objektno-relacionog mapiranja, t.j način na koji se može kreirati struktura baze podataka 
uz pomoć XSD fajla. Na slici 132. je pikazan alat XSD2DB Alexis Smirnova i grupe 
autora (može se na intemetu pronaći izvršna verzija kao i izvomi kod [192]) koji je 
primenjen na RequestToCancelPayment šemu . Šeme koje su preuzete od IS020022 
organizacije nisu nonnalizovani XML dokumenti [108], pa postoje dve solucije u 
korišćenju alata: 1. izvršiti normalizaciju XML dokumenta, pa kreirati konceptualni 
model baze podataka ili 2. kreirati bazu iz postojeće XSD šeme i normalizaciju baze 
podataka izvršiti naknadno. Slika 132. prikazuje gde alat može da se preuzme, 
mogućnosti alata, od čega je kreirana stmktura baze podataka i na koji način je kreirana 
stmktura baze podataka. 



Slika 131. Stmktura XSD šeme zahteva za otkazivanje plaćanja 
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~ C:\WINDOW5\system32\c md.e н e 


шт 


^ЈпјхЈ 


C:\Docunents and Settings\Slobodan\Desktop\xsd2db\xsd2db\bin\Release>xsd2db -h 
xsd2db 0.2.2842 - Utility to generate database based on a giuen XSD Schena 
hore Infornation: http://xsd2db.sourceforge.net 
-dbowner <-o> 

This is a prefix added to each table 
-force <-f> 

drop the database if it exists. 

-help <-h> 

Display usage instructions 
-location <-l> 

The type of database to connect to <servernane> 

-nane <-n> 

the nane of the database to be created 
-schena <-s> 

The the XSD file containing the schena 
-tableprefix <-p> 

This is a prefix added to each table 
-type <-t> 

The type of database to connect to [Jet S Sql S OleDb] 

C:\Docunents and Settings\Slobodan\Desktop\xsd2db\xsd2db\bin\Release>xsd2db -o s 
a -1 solaris -n UniuersalDB -s cant00800201.xsd -t Sql 

xsd2db 0.2.2842 - Utility to generate database based on a giuen XSD Schena 
hore Infornation: http://xsd2db.sourceforge.net 

C:\Docunents and Settings\Slobodan\Desktop\xsd2db\xsd2db\bin\Release> 


zi 


Slika 132. Kreiranje modela baze podataka alatom korišćenjem XSD šeme 


AmtToDbt 


— 

Ссу 

AmtToDbt_text 

Justfnjd 



Justfn 

JL 

CxlRsn 

ValDtToDbt 

Justfnjd 

camt00800201_Id 


Document 


jmentjd 


camt00800201 


camt00800201_Id 

Documentjd 




camtG08G02Gll 


CcyAmt 

Ссу 

CcyAmt_text 
Undrlyg_Id 


OO- 0з 


Undrlyg 


Assgnrlnstrld 


Assgnelnstrld 


ValDt 

Ч 

Undrlyg_Id 

— 

camtD0800201Jd 


Case 


Id 

Cretr 

ReopCaselndctn 

camt00800201_Id 


Assgnmt 


Id 
Assgnr 
Assgne 
CreDtT m 

" camt00800201_Id 


Slika 133. Model baze podataka kreiran XSD2DB alatom 


Model baze podataka, prikazan na slici 133. nije normalizovan i potrebno je izvršiti 
korekcije i normalizaciju da bi se dobio model zadovoljavajućih karakteristika. 
Poređenjem strukture XSD šeme sa slike 131. i modela baze podataka sa slike 133, 
može se izvršiti poređenje struktura. 

Ukoliko imamo XSD šemu i odgovarajuću strukturu baze podataka, moguće je uz 
pomoć alata doći do aplikativne strukture za unos, izmenu i brisanje odgovarajućih 
instanci u bazi podataka. U tu svrhu može da se iskoristi alat Altova MapForce [3], u 
kome ćemo izvršiti mapiranje xsd strukture u strukturu baze podataka. 

Mapiranje camt.008.002.01.xsd strukture u strukturu baze podataka sa slike 133. 
prikazano je na slici 134. Iz mapiranih struktura može da se generiše odgovarajuća 
aplikativna struktura u više programskih jezika, kao što je to prikazano na slici 135. za 
generisanje izvomog koda u C# [182] programskom jeziku, na slici 136. je prikazano 
uspešno generisanje koda. Prilikom generisanja korišćena je informacija o instanci sa 
IS020022 sajta, camt.008.002.01.xml u kojoj se nalaze testni podaci. 


Slobodan Babić \ Fakidtet organizacionih паика 


252 















































Doktorska disertacija: Model interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama 



Slika 134. Mapiranje XSD šeme i šeme baze podataka 


63 Altova MapForce - [xsd2db.mfd*] 


File Edit Insert Project Component Connection Function Output View lools Window 

Ч ixlxl imtimilgMi e 


D & Ц 


ilffi «0. Шј Ci. £2. 


ез 


В l^) xsd2db” 

B Čj Mapping Folder 


GJ UniversalDB 


^ Add Active File to Project.. 
^ Add Files to Project... 

m Create Folder... 


Open Mapping 

Open file in XMLSpy 


jHf^dbo.AmtToDbt 
Ef^šldbo.Assgnmt 
0[i=j]dbo .ca mt00800201 
Hf^ldbo.Case 
gjf^ldbo.CcvAmt 
gfi^dbo. Docu ment 
{j^DocumentJd 
*—Sf===]dbo .ca mt00800201 
jppa mt00800201 _ld 
{jf^DocumentJd 
Hf===1dbo .Assgn mt ca 


X 

Delete 

Delete 

% 

Сору 

Ctrl+C 

* 

Cut 

Ctrl+X 

ш 

Paste 

Ctrl+V 


Add Mapping File for Operation... 
Create Mapping for Operation... 


InsertWebService... 


Generate code 
Generate code in 


[j 3 Properties 





XSLT 1.0 

XSLT 2.0 

X£uery 

Java 

C# (Sharp) 1 


C++ 


''Л г 


; © |d 
gAssgnr 
igAssgne 
{jf^CreOtTm 
{gcamt00800201 
g[i=i]dbo.Case camtO 

I.© Id 

{gCretr 

{jf^Reop Case Indc 
{gpamt00800201 
+— Sf^ldbo. Justfn camt 
{jp|Cxl Rsn 
{jf^Val DtToDbt 

.{jjjjJustfnJd 

@=amt00800201 
♦—0[š=j]dbo. AmtTo Db 
ј ©Ссу 

{gAmtToDbtJ 
{jpjJustfnJd 
«— Elf^ldbo. Undrl yg сап 
{^Assgnrlnstrld 
{jp|Assgne Instr Id 
| {jgValDt 
| {gUndrlyg_ld 
@=amt00800201 


Slika 135. Izbor programskog jezika za generisanje koda za pristup bazi 
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.4 


Messages 


rC v] ▼Н 1 \®\ Ч I 1 x] 


O xsd2db.mfd: Project element validation successful - 0 error(s), 0 warning(s) 
O xsd2db.mfd: Mapping validation successful - 0 error(s), 0 warning(s) 

© Code generation completed successfully. 


. Messaaes 




л 


L |I Г " —•*• — 

®ValDt 

(gUndrlyg_ld 

@патГППНПП?П1 


Slika 136. Uspešno generisana aplikativna struktura 


Startovanjem konzolne aplikacije vrši se ažuriranje baze podataka i slika 137. prikazuje 
uspešan unos camt.008.002.01.xml instance u strukturu baze podataka. 


"C:\Documents and Settings\Slobodan\Desktop\Ksd2db\Hsd2db\bin\Release\output 


ЈШЈх, 


lapping flpplication 

Loađing C:/Documents and Settings/Slobodan/Desktop/xsd2db/xsd2db/bin/Release/cam 
;. 008 . 002 . 01 .xnl... 

"onnecting to UniuersalDB database... 

Pinished 

Press апу кеу to continue_ 


Slika 137. Uspešno ažuriranje baze podataka camt.008.002.01.xml instancom 


Izvomi kod Altova MapForce alatom generisane testne konzolne aplikacije izgleda 
ovako: 


using System; 
using System.Collections; 
using System.Data; 
using Altova.Types; 
using Altova.Functions; 
namespace Mapping 
{ 

public class MappingConsole 

{ 

public static void Main(string[] args) 

{ 

Console.Out.WriteLine("Mapping Application"); 

try 

{ 

TraceTargetConsole ttc = new TraceTargetConsole(); 

MappingMapToUniversalDB MappingMapToUniversalDBObject = new MappingMapToUniversalDB(); 
MappingMapToUniversalDBObject.RegisterTraceTarget(ttc); MappingMapToUniversalDBObject.Run( 

"C:/Documents and Settings/Slobodan/Desktop/xsd2db/xsd2db/bin/Release/camt.008.002.01 .xml", 

"Provider=SQLOLEDB.l; Data Source=SOLARIS; Lnitial Catalog=UniversalDB;Integrated Security=SSPI;Persist Security 
Info=False;"); Console.Out.WriteLine("Finished"); 

} 

catch (Altova.UserException ue) 

{ 

Console.Out.Write("USER EXCEPTION: "); Console.Out.WriteLine( ue.Message ); System.Environment.Exit(l); 

} 

catch (Exception e) 

{ 

Console.Out.Write("ERROR: "); Console.Out.WriteLine( e.Message); Console.Out.WriteLine( e.StackTrace); 
System.Environment.Exit( 1); 

} 

} 

} 

class TraceTargetConsole : Altova.TraceTarget { public void WriteTrace(string info) { Console.Out.WriteLine(info); 

} 

} 

} 
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U generisanoj testnoj konzolnoj aplikaciji nalazi se kod koji može da se koristi u bilo 
kom aplikativnom sistemu za rad sa bazom podataka nad kojom je konstruisan. Na isti 
način se može postupiti i za sve ostale šeme date na IS020022 sajtu, kao i za druge xsd 
strukture. 

Ovaj primer pokazuje da je moguće od xsd strukture, kojima se vrši zadavanje 
standarda, korišćenjem dostupnih alata doći do elemenata sistema koji imaju 
zadovoljavajuće karakteristike. Svi dobijeni elementi platnog sistema koji su opisani 
postoje u mnogim verzijama, sa posebnim osobinama na tržištu. Dobijeni elementi 
predstavljaju odličnu osnovu za razvoj projekta, ali i polazište za izgradnju novih, 
karakterističnih alata koji bi u još većoj meri mogli da automatizuju razvoj aplikativnih 
elemenata platnih sistema. 

Procesiranje transakcija u elektronskom poslovanju platnih sistema implementira se na 
način koji je opisan u primeru RTGS procesiranja. Tabela Stanja RTGS sistema sadrži u 
sebi informacije o stanjima računa banaka u RTGS sistemu. To su računi na koje se vrši 
priliv i odliv sredstava kada se izvršavaju transakcije Retail korisnika banaka. Prilikom 
rada RTGS sistema moguće je da dođe do unakrsnog zaključavanja računa odnosno do 
pojave Greed Locka. Rešenje je primena nekog od Greed Lock Resolution algoritma. Na 
tabeli Stanja postavljen je triger. Triger nad tabelom Stanja ima zadatak da, kada se 
promeni stanje na računu pokuša da izvrši još jednu transakciju koja je u bazi podataka 
zapisana sa stanjem „па čekanju za izvršenje zbog nedostatka sredstava“. Taj pokušaj 
izvršenja transakcije vrši se nad računom na kome su dodata sredstva, tako da postoji 
šansa da zbog priliva na račun one transakcije koje nisu mogle da se izvrše postanu 
izvršive. Na taj način se redukuje broj transakcija koje ne bi bile realizovane zbog 
nedostatka sredstava na računima banaka. Smanjuje se i verovatnoća unakrsnog 
zaključavanja računa i povećava verovatnoća situacije ukoliko bi neke transakcije koje 
čekaju na red bile izvršene na ovaj način, da red za čekanje bude smanjen ili prazan. 
Izvomi kod trigera nad tabelom dat je u Prilogu 9. 

Navedeni triger je primer elementa koji služi za jednu od funkcija procesiranja. I ostali 
elementi sistema za procesiranje mogu da se izvedu u istoj tehnici, ali moguće je istu 
stvar uraditi i na više drugih načina. Kada je poruka stigla u sistem i kada je zabeležena 
u bazu, završen je jedan segment poslova vezanih za procesiranje. Tačka kada je pomka 
zabeležena u bazu može biti tačka prekida, kada se ostali procesi koji su potrebni da se 
odigraju mogu odvijati asinhrono u odnosu na nju, ali može da bude i tačka u kojoj se 
procesi nastavljaju događati kontinuirano, bez prekida, tako da se sve ostale potrebne 
radnje moraju izvršavati sinhrono. Izvršeno je laboratorijsko ispitivanje da bi se utvrdilo 
da li je bolje da procesi koji slede budu nezavisni od prethodnih, odnosno asinhroni, ili 
da budu u kontinualnom sledu, odnosno sinhroni. Zaključak je da je bolja osobina 
asinhronosti procesa i da je bolje da sistem ima što više asinhronih tačaka prekida. 
Procesiranje se odvija nezavisno po segmentima, i u slučaju da dođe do prekida procesa, 
mogu se i sa nekim dmgim elementom za procesiranje izvršiti procesi koji nedostaju. 
Ukoliko je ambijent za procesiranje nestabilan, postojaće manji broj grešaka o kojima se 
vodi računa. Dugački procesni lanci moraju da imaju mnogo komfomije uslove u 
kojima se odvijaju i imaju duži životni vek, čime se povećava verovatnoća negativnog 
delovanja ambijentalnih uslova. Ukoliko postoji veliki broj dugoživućih lanaca procesa, 
oni zauzimaju značajno više životnog prostora od istog broja kratkoživučih, asinhronih 
procesa. 
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6.6 Primena rešenja 

U ovom poglavlju analiziran je značaj informacionih tehnologija, interoperabilnosti i 
sigurnosti u elektronskom poslovanju platnih sistema i njihova kolaboracija sa 
sistemima lanaca snabdevanja, standardnim sistemima posebne namene, sistemima 
drugih finansijskih organizacija, kao i sistemima koji čine osnovu koja omogućava 
doslednu i zakonski ispravnu kolaboraciju svih sistema. 


6.6.1 Komponente sistema 

Kompanija Dunav osiguranje a.d.o. u svojim poslovnim procesima u interakciji je sa 
mnoštvom raznorodnih sistema bez kojih ne bi bilo moguće ostvariti poslovni uspeh i 
paletu proizvoda koje jedno savremeno osiguravajuće društvo treba da ponudi tržištu. 
Svaka poslovna transakcija Kompanije praćena je sa jednom ili više finansijskih 
transakcija. Poslovne transakcije i sa pravnim i fizičkim licima u svim segmentima 
poslovanja obavljaju se na način koji je do sada bio uobičajen u praksi u Srbiji, koja 
preovladava u poslovnim procesima osiguravajućih društava. 


Osiguranik 





M inistarstvo 
unutrašnjih poslova 




Kompanija Dunav 
osiguranje 
(KDO) 



EUROTax 




4 


UBS sistem 


RTGS 

direktnog zaduženja 


Narodnebanke srbije 


Legenda: 

1. Kupovina osiguranja 

2. Prijava štete 

3. Slanje zapisnika o udesu 

4. Slanje specifikacija štete 

5. Procena štete 

6. Slanje specifikacije i procene štete 

7. Slanje specifikacija štete 
8.1 spostavljanje fakture 

9. Inicijalizacija Mandata KDO 

10. Inicijalizacija Mandata DA 

11. Realizacija Mandata u UBS 

12. Obaveštavanje o popravci 

13. Realizacija u RTGS sistemu 


Slika 138. Učesnici i osnovni potprocesi u procesu prijave štete 

Uvođenjem sistema za direktna zaduženja u Udruženju banaka Srbije stvorena je 
osnova za inovaciju proizvoda, ali i načina poslovanja. Finansijske transakcije se 
obavljaju sistemom elektronskog bankarstva i ne postoji mogućnost iniciranja 
transakcija sa unosnog mesta gde nastaju podaci, već se naknadno, na osnovu 
informacija u informacionom sistemu, vrši uparivanje transakcija sa rezultatima 
poslovnih transakcija. Na taj način se troše resursi i vreme poslovnih transakcija nije 
predvidivo. Standardi u finansijskoj industriji osiguravajućih društava omogućavaju i 
Retail i korporativnim klijentima da izvrše naručivanje proizvoda osiguravajućeg 
društva kao i svaki drugi proizvod korišćenjem savremenih informacionih tehnologija 
[101] i da na taj način da učine tačnijim i bržim procese koji prate poslovne procese 
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osiguravanja i reosiguranja. Standardi lanaca snabdevanja daju mogućnost da se, kao i 
za sve ostale proizvode potreban materijal, alat i rezervni delovi proizašli iz sistema za 
procenu, mogu na brz i efikasan način standardnim porukama naručiti i pratiti izvršenje. 
Sistem za autorizaciju i očuvanje konzistentnosti poruka i podataka u njima, kao i telo 
za registraciju poruka čuvaju konzistentnost podataka i procesa i na taj način 
omogućavaju izvršavanje poslovnih procesa u okvirima zakonske regulative. 

Pored nabrojanih transakcija u procesu koji je prikazan na slici 138, nisu prikazane 
finansijske transakcije od interesa, među kojima su i: kupovina osiguranja, troškovi 
izdavanja zapisnika MUP-a oštećeniku i KDO-u, troškovi izrade vrednosti štete na 
osnovu specifikacije, troškovi banke za uslugu sklapanja mandata za DA i mandata za 
auto servis, troškovi iniciranja finansijske transakcije putem eBankinga (za Autoservis i 
DA), troškovi banke za izvršenje finansijske transakcije direktnog zaduženja, troškovi 
UBS za bruto poravnanje i drugi. 


« 

S. 



Slika 139. Dekompozicija složenog procesa 

Svaki od navedenih procesa složen je najmanje od sledećih procesa, prikazanih na slici 
139: provere potpisa, skladištenja u Dunav arhivu po protokolu Dunav arhive kao tela 
za registraciju poruka i navedenog toka. Iz ovoga sledi da Dunav arhiva kao telo za 
registraciju poruka mora da bude vlasnik, da adresiranje podrazumeva automatsko 
rutiranje poruke ka Dunav arhivi koja poruku u jednoj transakciji skladišti, priprema za 
slanje i šalje učesniku na koga je poruka adresirana. 

6.6.2 Realizacija sistema 

6.6.2.1 Realizacija sistema lanaca snabdevanja 

Poslovni partneri u svakom segmentu specijalizovani su za odgovarajući segment 
poslovanja. Danas je veoma retko da se proizvođači bave i distribucijom; u nekim 
oblastima, kao što je u farmaciji, u nekim zemljama proizvođač ne sme da se bavi i 
prodajom lekova na malo i slično. Klirinška kuća je specijalizovana da vodi računa o 
potrebnim resursima za transport i procesiranje standardizovanih poruka, iz mnoštva 
kombinacija koje se nude nekim standardom klirinška kuća propisuje podstandard, ona 
vodi računa o svim aspektima sistema: dokumentima sistema, standardima, 
metodologiji, tehnologiji, organizaciji, kadrovima, sistemskom softveru i hardveru. 

Klirinška kuća može da bude neprofitna organizacija. Primer za takav vid organizacije 
je SWIFT ili profitna organizacija, kao što je na primer Udruženje banaka Srbije. U oba 
slučaja, procesorska kuća organizuje svoje poslove u skladu sa Operativnim pravilima, 
dokumentom Format i namena poruka i Tehničkim uputstvom. Uz navedena 
dokumenta, softverske module za slanje i prijem poruka, klirinške kuće sve češće 
determinišu i druge elemente sistema: sertifikate potrebne za potpisivanje i kriptovanje 
sadržaja, odgovarajuće XML šeme i pripadajuće im modele. 
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U većini slučajeva partneri žele da budu povezani sa klirinškom kućom i da razmenjuju 
poruke putem opisane infrastrukture klirinške kuće. Da bi ustanovila konzistentnu 
razmenu, klirinška kuća obezbeđuju potrebne resurse uključujući i potrebne mrežne 
resurse, softverske module za slanje i primanje standardnih poruka, odgovarajuće 
rutiranje poruka, procesiranje i skladištenje podataka o partnerima, proizvodima i 
katalozima, mogućnost pretrage dozvoljenih skupova onlajn, na sajtu procesorske kuće, 
kao i da neki manji poslovni sistemi mogu da zadovolje i ostale potrebe pri pretrazi i 
zboru partnera, proizvoda ili kataloga. 

Prvi način komunikacije jeste da klijent može da adresira (pošalje poruku) samo 
klirinšku kuću. Klirinška kuća može, u zavisnosti od sadržaja poruke i ovlašćenja, da 
izvrši odgovarajuće procesiranje koje može da uključi i slanje poruke nekom drugom 
svom participantu. 

Drugi način komunikacije možemo da definišemo kao komunikaciju između klirinških 
kuća, gde jedna klirinška kuća može da adresira drugu klirinšku kuću. Pri tome jedna 
klirinška kuća ne može direktno da adresira klijente druge klirinške kuće, već klirinška 
kuća koja prima poruku može da izvrši odgovarajuće procesiranje koje može da uključi 
i slanje poruke svom participantu. 

Treći način komunikacije uključuje i prvi i drugi. Na taj način, klijent jedne klirinške 
kuće dobija mogućnost adresiranja klijenta druge klirinške kuće. I klirinška kuća dobija 
mogućnost adresiranja klijenata druge klirinške kuće. Na ovaj način dobija se 
konzistentan adresni prostor učesnika u razmeni poruka u lancu snabdevanja. 

Proces prerade (procesiranja) poruka sastoji se od sledećih aktivnosti: pribavljanja i 
provere administrativnih privilegija za pristup ulaznim podacima, skladištenja ulaznih 
informacija, primene tehnološkog procesa obrade , odgovarajućeg broja operacija, 
skladištenja izlaznih informacija i davanja administrativnih privilegija za pristup 
izlaznim podacima. 



Slika 140. Izbor šeme u dokument kreatoru Sylus Studi-a 

Navedeni proces je tretiran kao bilo koji tehnološki proces, na primer iz mašinske 
industrije. Postojanje XSD (XML Schema Definition ili skraćeno XSD je XML bazirani 
jezik koji se koristi da opiše i kontroliše sadržaj XML dokumenata) šema determiniše 
skladišta ulaznih podataka i na taj način determiniše i elemente sistema (klase i relacije 
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između njih), što može da se iskoristi za pisanje sekvenci operacija tehnologije 
potrebnih za izradu modula za procesiranje. 

Realizacija sistema lanca snabdevanja vrši se na isti način kao i realizacija sistema za 
Credit Transfers [21]. Na slici 140. je predstavljen dokument kreator u XML alatu Svlus 
Studio [202]. U kartici XML Editor može se izabrati EANCOM to XML Schema opcija. 
Na taj način omogućavamo kreiranje XSD šeme sa odgovarajućom strukturom u koju 
može da se mapira struktura izabrane standardne EANCOM poruke. 


Klikom na taster OK dobija se mogućnost izbora verzije standarda poruke i vrsta 
poruke. U polju za izbor nalazi se svih 49 mogućih dcfinisanih poruka. Postoji 
mogućnost još nekih opcija za kreiranje ako se izvrši izbor kao na slici 141. 


Create XML Schema from EANCOM Message Definition 


XJ 


Version: [2002 ^] 


Message: 


Message 

Description 

-— Г1 

MSCONS 

ORDCHG 

ORDERS 

Metered Services Consumption Report 

Purchase Order Change Request 

Purchase Order 


ORDRSP 

0STENQ 

OSTRPT 

Purchase Order Response 

Order Status Enquiry 

Order Status Report 

1 

IPARTIN Partv Information ж 

PAYMUL 

PRICAT 

PRODAT 

РРП1МП 

Multiple Payment Order 

Price/Sales Catalogue 

Product Data 

Prnrll IV't 1 ПП 1 liril 

zi 


P Include annotations describing each element 
W Generate enumerations for elements that have codelists 
W Use jong element names 

W Use "unbounded" for maxOccurs when loop value is 99 or higher 
(accommodates limitations in many validators) 

(• Batch sohema C Interactive schema 


OK | Cancel 


Slika 141. Izbor verzije željene EANCOM poruke 


Nakon izvršenog kreiranja XSD sheme i uklanjanja jednog opcionog noda, dobija se 
struktura kao što je to prikazano na slici 142. Kreirana XSD shema može da se mapira 
sa originalnom EANCOM porukom uz pomoć koje je generisana. 



Slika 142. Generisana strukturaXSD šeme 
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Na osnovu XSD sheme moguće je izvršiti kreiranje baze podataka XSD2DB alatom. 
Kreirana baza podataka može da se mapira šemom iz koje je generisana. 

Iz prethodnog sledi da bilo koja EANCOM 2002 poruka lanca snabdevanja može da se 
mapira sa odgovarajućom šemom baze podataka, koja je nastala na način koji je 
prethodno opisan i prikazan na slici 143. Postojećim alatima moguće je generisati i 
odgovarajuće dinamičke biblioteke za insertovanje poruka u bazu i ekstrahovanje 
poruka iz baze. Iz prethodnog sledi da sve EANCOM 2002 poruke koje su primljene i 
koje se šalju mogu biti uskladištene u bazi podataka i nad njima se mogu vršiti 
odgovarajuće operacije koje su indukovane poslovnim zahtevima. Navedeni elementi 
mogu se generisati za potrebe procesorske kuće ili preduzeća. 

U procesorskoj kući se generiše data pool koji je centralizovano mesto na kome se 
skladište informacije o partnerima, njihovim proizvodima ili servisima i odgovarajućim 
katalozima. Slična preslikavanja i elementi sistema generišu se i kod participanata za 
njihove potrebe. 


t PARTIN 


Јв OEnuelope 

ED Olnterchange 


aOUHB NTERCHANGE HEADER 
OOSOOI SYNTAX IDENTIFIER 
Ш OS002 INTERCHANGE SENDER 
Ш <>S003 INTERCHANGE RECIPIENT 
Ш OS004 DATE AND TIME OF PREPARATION 
= F0020 INTERCHANGE CONTROL REFERENCE 
j-ffl OS00S RECIPIENT REFERENCEiPASSWORD DETAILS 

. = F0026 APPLICATION REFERENCE 

I. = F0029 PROCESSING PRIORITY CODE 

=F0031 ACKNOVVLEDGEMENT REOUEST 



Hdbo.EDIFACT 

OffEDIFACTJd 

-Ш Hdbo.PARTIH EDIFACTJd 
-Ш Hdbo.UHB EDIFACTJd 

0 UNB05-lnterchangeControlReferer 
D UHB07-ApplicationReference 
D UNB08 ProcessingPriorityCode 
D UHB09-AcknowledgementRequesi 
D UNBIO-lnterchangeAgreementldei 
D UHB11 -TestIndicat ог 
DfUHBJd 
DflEDIFACTJd 


Slika 143. Mapiranje šeme poruke sa bazom podataka 


Danas se u praksi javlja veliki, gotovo nepremostiv problem u preduzećima - mapiranje 
iz, uglavnom sopstvenog formata, u neki standardan format. Pokazuje se da je jedan 
takav, gotovo trivijalan problem, prerastao u veliki i nepremostiv problem 
umnožavanjem broja mapiranja. Bez korišćenja alata, ovo često prestavlja veliki zahvat, 
od same analize problema, pa do implementacije. Danas je praksa da se od primene 
ovakvih sistema odustaje već prilikom analize ovakvih koraka. 


6.6.2.2 Realizacija Eurotax sistema 

Zahtev kompanije „Dunav osiguranje“ jeste da se izvrši centralizacija podataka procene 
šteta na osnovu programa Eurotax EMU koji će omogućiti centralizaciju podataka 
vezanih za pružanje usluge procene štete na motornim vozilima kao i omogućavanje 
arhiviranja dokumentacije nastale prilikom procene, omogućavanje arhiviranja raznih 
dokumenata vezanih za procenu štete na arhivskom serveru kompanije a vrši se i 
formiranje baze podataka na osnovu podataka iz Eurotaxa koja služi kao osnova za 
formiranje raznih vrsta pregleda i izveštaja. Postoji mogućnost povezivanja sa 
projektima prijave i likvidacije šteta, kao i sa projektom rezervacije šteta. 
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Implementirani su sledeći moduli, prikazani na slici 144: Modul za povezivanje sa 
Eurotaxom sistemom u EU, modul šifarnika sa vrstama, modelima i tipovima vozila, 
delovima automobila, modul za pohranjivanje podataka o proceni štete, modul za 
povezivanje sa arhivskim serverom Dunav Arhiva za arhiviranje raznih vrsta 
dokumenata, fotografija i xml-ova, modul za povezivanje sa postojećim modulima za 
prijavu, rezervaciju i likvidaciju šteta infonnacionog sistema Kompanije Dunav 
osiguranje. 


Eurotax EMU 

1 

Dunav -sql server 



Dunav -Arhiva 


Procenitelj - Beograd 


Procenitelj - Novi Sad 

& <9 

Procenitelj -Niš 

&& 

Ostali procenitelji (47) 





Direkcija 


WS: 

1. Provera postojanja 
zadate procene 

2. Vraćanje informacije o 
postojanju procene (xml 
poslednje procen ili 0 ako 

ne postoji) 

3. Dobijanje podataka o 

novoj proceni 

4. Slanje potvrde o upisu 
nove procene u SQL bazu 


WS: 

1. Slanje xml-a u arhivu 

2. Vraćanje poslednjeg 

xml-a 

3. Smeštanjefotografija i 
ostalih dokumenata u 
arhivu 

4. Vraćanje traženih 
dokumenata iz arhive 



SQL: 

1. Provera postojanja xml-a 

2. Raspakivanje nove procene (xml) u bazu 

3. Slanje nove procene (xml) u arhivu 

4. Vraćanje poslednje tražene procene (xml) 
Eurotaxu 

5.Slanje dokumentacije (fotografije,obračuni, 
saobraćajna...) u arhivu 

6. Pregled dokumentacije iz arhive po zadatim 
parametrima 

7. Pregledi procena po referentnom broju 

8. Statistički izveštaji 

9. Povezivanje sa projektima prijave,rezeravcije 
i likvidacije štete 


Slika 144. Sistema za centralizaciju procene štete 
i arhiviranje pripadajuće dokumentacije 
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Trenutno se program Eurotax koristi na oko 50 lokacija, procena šteta se radi za potrebe 
kompanije Dunav osiguranje i uslužno za druga pravna i fizička lica, slika 144. Procene 
se sastoje od standardne dokumentacije zadate zakonskom regulativom, obračunima, 
kalkulacijama i fotografijama oštećenih automobila koji se čuvaju u Dunav arhivi, sa 
mogućnošću uvida od strane rukovodilaca ili drugih procenitelja. Svaka procena dobija 
svoju referentnu oznaku. Procena štete se može vršiti pre i posle prijave štete u sistemu 
Kompanije. Povezivanje sa prijavom se može izvršiti preko intemog referentnog broja - 
unosi se mašinski broj prijavljene štete. Dokumenti koji se eksportuju iz Eurotax 
sistema i koji se prikupljaju prilikom procene šteta su: zapisnik o oštećenju vozila, 
kalkulacija, obračun o visini štete, fotografije oštećenog automobila, skenirane vozačke 
i saobraćajne dozvole, zapisnici MUP-a, evropski izveštaji. Procena štete se može vršiti 
više puta i svaka kalkulacija se vodi pod istim referentnim brojem procene i novim 
brojem kalkulacije. 

Pošto se podaci čuvaju centralizovano, postoji mogućnost uvida u procenu štete od 
strane rukovodstva ili drugih procenitelja radi kontrole. Moguće je uraditi dodatnu 
procenu od strane drugih procenitelja sa svake lokacije procene štete i omogućeno je 
praćenje rada procenitelja i dobijanje izveštaja vezanih za njihov rad. Moguć je uvid u 
sve procene urađene u Dunav osiguranju i mogućnost praćenja rada procenitelja. 
Stvoren je okvir za formiranje raznih izveštaja o procenama, oštećenim delovima, kao i 
mogućnost povezivanja sa prijavom, rezervacijom i likvidacijom štete. 

6.6.2.3 Realizacija sistema osiguranja 

Trendovi u razmeni podataka u sistemima, pa i sistemima osiguranja, jesu u 
obezbeđivanju razvoja adekvatnih otvorenih standarda za razmenu poslovnih 
dokumenata na iskustvima standarda i neprofitnih organizacija kao što je u finansijskoj 
industriji SWIFT organizacija. U industriji osiguranja takav primer je i organizacija 
ACORD [1]. ACORD (. Association for Cooperative Operations Research and 
Development) je globalna, neprofitna organizacija koja razvija standarde u službi 
industrije osiguranja i odgovarajućih industrijskih finansijskih servisa. ACORD-ova 
misija je da pospeši dogovore u razvoju otvorenih standarda podataka i formi standarda. 

ACORD članov čine veliki broj osiguravajućih i reosiguravajućih kompanija, agenata i 
brokera, proizvođača softvera i pripadajućih industrija širom sveta. ACORD ima cilj da 
obezbedi razmenu podataka između različitih platfonni i inplementacionih standarda, 
odnosno na standardima za razmenu informacija između sistema i partnera. ACORD 
Standards and services utvrđuje standarde za kvalitet podataka i njihovu 
transparentnost, što rezultuje većom efikasnošću i proširenjem tržišta na kojima je 
zastupljen XML. 

ACORD XML pokriva i zahteve u realnom vremenu u odnosu na poslove sa poslovnim 
transakcijama korišćenjem klijent-server okruženja kroz adekvatne sisteme poruka. 
ACORD XML obezbeđuje željeni otvoren i efikasan način transfera strukturiranih 
podataka između aplikativnih sistema i partnera. Najveća korist od uvođenja 
elektronske razmene podataka u osiguranju jeste tačnost i pravovremenost informacija. 
Postiže se mogućnost i sledljivosti proizvoda, kao i povećavanje različitih pozitivnih 
ekonomskih aspekata korišćenjem elektronske razmene dokumenata, pogotovu ukoliko 
je elektronska razmena centralizovana preko biroa za procesiranje. 
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Zakonska regulativa u većini zemalja ima tendenciju da se prilagodi novim 
infonnacionim tehnologijama koje mogu da se uvedu u poslovanje, pa i u poslovne 
procese kompanija koje se bave osiguranjem. Važni aspekti su defmisani ili se definišu 
u mnogim zemljama u okviru zakonskih regulativa povezanih sa elektronskim potpisom 
[136], digitalnim dokumentima [144] i elektronskim poslovanjem. 

U skladu sa zakonskom regulativom, razvija se i svest o uzorcima koji mogu da budu 
korišćeni da bi se informatički podržalo takvo poslovanje. Razvijen je čitav niz uzoraka 
za integraciju [90], od kojih je jedan i Dokument Message uzorak [14], pa je čak i 
savremena arhitektura [85] servisno orijentisana, prilagođena sadašnjim saznanjima i 
novim standardima. 

Uvođenje standarda ACORD podrazumeva tri osnovna koraka sa svojim potprocesima: 
organizacioni, fu nk cionalni i tehnički korak, kako je prikazano u tabeli 21. Razvijenje i 
ACORD Framework koji je skup od pet modela potrebnih za razvoj ACORD standarda. 
ACORD Framework se sastoji od poslovnog rečnika, informacionog modela sa 
odgovarajućim konceptima koji sadrži i model podataka, modela komponenata i 
poslovnog modela, prikazanih na slici 145. Vrši se standardizacija „servisa poslovnih 
procesa”, i to tako što se ne mora kreirati ACORD poruka za svaki proces koji se 
definiše prateći servis orjentisanu arhitekturu da se mogu kreirati vlastite poruke 
bazirane na ACORD XML standardu podataka u svrhu razmene podataka između 
procesa. 

U nameri standardizacije podataka baziranih na UML metodologiji modeliranja, 
ACORD se opredelio za metodologiju u Core СотропепГ razvijenu od strane 
UN/CEFACT kao kompatibilnu osnovu za razvoj ACORD rečnika podataka. 
UN/CEFACT [218], OASIS/UBL [157] i ostale organizacije za razvoj standarda 
napravile su značajan napredak radeći zajedno na jedinstvenom imenovanju i pravilima 
izrade (odnosno na UML NDR - Universal Business Language, Naming and, Design 
Rules) pristupa koji postavlja XML standarde podataka za generisanje skupa pravila 
standarda direktno iz Core Component modela. ACORD poslovna poruka je skup 
elemenata i/ili agregata, koji se prosleđuju od klijenta ka serveru kao zahtev ( Request 
Message) ili od servera ka klijentu kao odgovor ( Response Message). Poruka sa 
odgovorom je tipičan nadskup zahteva koji sadrži odgovor zajedno sa zahtevom. Tipovi 
poruka se definišu ACORD specifikacijom i podržavaju sledeće poslovne transakcije: 

• Add ACORD poruka se koristi za kreiranje nove instance objekta; 

• Inquiry ACORD poruka se koristi za pribavljanje kvota za objekat ili 
informaciju o stanju određenog objekta; 

• Submit ACORD poruka se koristi za prosleđivanje podataka i razlikuje se od 
Add poruke po torne što poruka Submit infonnativna i ne zahteva određene 
privilegije; 

• Modification ACORD poruka se koristi da izmeni instancu ili objekat; 

• Cancellation ACORD poruka se koristi za otkazivanje ili otkazivanje 
zanavljanja postojeće instance objekta; 

• Renewal ACORD poruka se koristi za obnavljanje instance ili postojećeg 
objekta; 

• Reinstatement ACORD poruka se koristi da ponovo instancira postojeći 
objekat; 

• Reissue ACORD poruka se koristi da prepiše instancu od postojećeg objekta; 
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• Synchronization ACORD poruka se koristi da obezbedi instancu specifičnog 
objekta od strane servis provajdera usluge. 


PROCES 

OPIS 

Organizacioni 

procesi 

Provera ciljeva. 

Proglašavanje intemog lidera u svakoj organizacionoj jedimci. 

Uključivanje poslovnih i IT kadrova u svakom od koraka procesa. 

Definisanje zajedničkih rokova sa poslovnim subjektima i intemim i ekstemim. 
Utvrđivanje zajedničkih radnih i statusnih sastanaka. 

Utvrđivanje potrebnih resursa i zahteva za praćenje. 

Funkcionalni 

procesi 

Defmisanje podmčja implementacije (tipova pomka, transakcija, LOB itd). 

Razvoj poslovnog slučaja. 

Razvoj funkcionalne specifikacije koja uključuje dijagrame tokova, specifične 
fičere, zahteve za podacima očekivanja i slično. 

Validiranje i sinhronizaciju potreba za podacima.. 

Identifikacija svih poslovnih entiteta. 

Praćenje zavisnosti i utvrđivanje svih promena sa svim uključenim stranama u 
komunikaciji. 

Odlučivanje o potrebnim inicijalnim konverzijama podataka. 

Defmisanje potrebnog nivoa informacija za mapiranje podataka. 

Mapiranje potrebnih podataka. 

Specificiranje procesa automatizacije (potpuno automatizovanje, validacija 
korisnika, kontrole itd). 

Pažljivo preispitivanje ACORD prepomka, uputstava za implementaciju u smislu 
obaveznih polja, kurseva za razmenu i poslovnih pravila. 

Dcfmisanje prava, autorizacije i načina pristupa nestrukturiranim informacijama. 
Identifikacija vlasnika prava i zaštite u svakoj organizaciji. 

Dogovor oko kriterijuma prihvatanja. 

Dogovor oko korekcije procesa. 

Tehnički 

procesi 

Dogovor oko standarda. 

Usaglašavanje oko verzije protokola (pomka, SOAP /Web profila servisa i drugih 
sličnih aspekata). 

Dogovor oko načina na koji se pristupa nestmkturiranim podacima (skladište 
dokumenata, FTP itd). 

Tri faze ispomke: 

1 . Test faza na specifičnom okruženju. 

2. Pilot faza sa radom na tradicionalni način - u papirnoj formi i sa XML pomkama. 

3. Produkcina faza samo sa XML pomkama. 


Tabela 21. Osnovni koraci za uvođenje standarda 

Standard ACORD definiše strukturu poruke koja je predstavljena na slici 146. ACORD 
poruke se mogu podeliti i po oblastima kojima pripadaju, po odgovarajućim područjima 
za koje se vrši standardizacija poslovnih procesa. Podela po područjima ACORD 
standardizacije prikazana je na slici 147. 



Slika 145. ACORD Framework za razvoj standarda 
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Standard Akord opisuje i osnovne segmente razvoja i standardizacije koji se mogu 
primeniti u kreiranju biroa za procesiranje sa ACORD ili drugim standardom za poruke. 
Definisane poruke i segmentirani razvoj pokrivaju sve potrebne poslovne procese za 
određeni poddomen i mogućnost za započinjanje komunikacije u smislu razmene 
osnovnih informacija o poslovnim transakcijama ili onima koje ih opisuju. 
Standardizacija indukuje i potrebu za razvoj i uspostavljanje sigurnog puta za 
komunikaciju, uz pomoć kojega bi mogla da se vrši razmena potrebnih informacija sa 
valjanim mehanizmima povratne sprege, na nivou fizičke razmene putem 
komunikacionog kanala i na nivou poslovne komunikacije, odnosno potrebu za 
korišćenjem specijalizovanog sistema za razmenu standardizovanih poslovnih poruka. 

Message structure 



Slika 146. Struktura ACORD poruke 


ACORD Messaging Library (AML) 
AML Architecture 

ACORD Web Services Profile (AWSP) 
Catastrophe Exposure Data Standards 
Data Model 
Information Model 
Product Schema 


Slika 147. Područja ACORD standardizacije 
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6.6.2Л Dunav arhiva registraciono telo 

Kod planiranja razvoja i kreiranja arhitekture sistema Dunav arhive pošlo se od 
osnovnih zahteva koji su postavljeni pred projekat, a to su potpuno ispunjenje zadatih 
fu nk cionalnih zahteva impliciranih zakonskom regulativom, kao i visoka raspoloživost, 
visoke performanse, pouzdanost i skalabilnost. U pogledu performansi sistema 
postavljen je zahtev za obradom većeg broja konkurentnih zahteva za pregledanje 
podataka u arhivi. U pogledu skalabilnosti postavljen je zahtev da se povećanje 
kapaciteta/perfonnansi sistema može lako ostvariti umnožavanjem postojećih delova 
sistema (npr. dodavanjem novih servera). 

Sistemje realizovanu troslojnoj softverskoj arhitekturi. Slojevi arhitekture su: 

• korisnički interfejs koji se sastoji od prikaza logičkih celina sistema: Pregled 
arhive, Pretraga, Administracija; 

• sloj poslovne logike sistema koji na osnovu korisničkog zahteva liltrira tražene 
podatke i prezentuje ih korisničkom interfejsu; 

• sloj podataka koji je predstavljen sa sistemom za upravljanje relacionom bazom 
podataka; na slici 149 predstavljen je dijagram baze podataka. 

Aplikativni podsistem zadužen za import podataka u bazu realizovan je u vidu klijent- 
server aplikacije i predstavlja važan segment jer omogućava automatizovani import 
podataka u bazu. Na slici 148. prikazana je logička arhitektura sistema. 



Za realizaciju korisničkog interfejsa korišćena je tehnologija ExtJS verzije 3.3. ExtJS 
predstavlja javascript bazirani framework koji svojim širokim spektrom mogućnosti 
omogućava kreiranje modernog i intuitivnog korisničkog interfejsa. Kao klijentska 
aplikacija može se koristi bilo koji od opšteprihvaćenih, veb-browsera koji podržava 
javascript. Korišćenje ExtJS-a za kreiranje korisničkog interfejsa omogućilo je punu 
nezavisnost od veb-browser-a i klijentskog operativnog sistema. Za komunikaciju 
između korisničkog interfejsa i sloja poslovne logike koriste se АЈАХ pozivi. Na taj 
način se postiže maksimalna brzina prikaza podataka na korisničkom interfesju pošto se 
na ovaj način osvežavaju delovi korisničkog interfesja koji su se menjali. 
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Sloj poslovne logike realizovan je korišćenjem PHP tehnologije. PHP je izabran zbog 
svoje portabilnosti i visokih performansi koje pruža, bez obzira na kom operativnom 
sistemu radi (Linux,Widows). Za realizaciju ovog projekta korišćena je verzija 5.3 sa 
standardnim setom klasa i funkcija. Za komunikaciju između sloja poslovne logike i 
sistema za upravljanje bazom podataka korišćen je Microsoft PHP-SQL driver. 
Korišćenje ovog driver- a daje najbolje performanse u komunikaciji sloja poslovne 
logike sa bazom. 

Aplikacija za import podataka kreirana je u .Net tehnologiji kao Windows klijentska 
aplikacija. Aplikaciju će prevashodno koristiti operateri, čija će dužnost biti učitavanje 
podatka u sistem. Aplikacija je kreirana iz više koraka: 

• prvo je na osnovu usvojene XSD šeme kreirana pomoćna baza podataka; ovo 
je urađeno uz pomoć open source softver XSD2DB 
(http://xsd2db.sourceforge.net/) , koji kreira SQL Server bazu podataka; 

• uz pomoć softvera Altova Map Force kreirana baza podataka mapira se 
šemom iz koje je kreirana; navedeni alat ima mogućnost kreiranja .Net C# 
aplikacije koje će vršiti učitavanje XML instance kreirane na osnovu XSD 
šeme u pomoćnu bazu podataka; 

• ručna dorada kreiranog C# koda, kako bi se obezbedilo višestruko korišćenje 
aplikacije i visok stepen automatizacije procesa; u ovom koraku su odrađene 
i ostale funkcionalnosti aplikacije, koje pokrivaju ceo proces importa 
podataka. 

Masovni import arhivističke građe koji se isporučuje od isporučioca skenirane građe i 
odgovarajućih metapodataka podeljen je u sledeće opracije: 

• onemoguće se dolazni servisi, odnosno Apache web server kako bi bio 
onemogućen pristup produkciji preko veb-aplikacije Dunav arhiva; 

• uradi se backup produkcione baze podataka sa aktuelnim stanjem; 

• uradi se privremena deaktivacija indexa na najbitnijim tabelama Dokument i 
DokumentAtribut; 

• izvrši se import metapodataka u inicijalnu bazu podataka; u ovom koraku se vrši 
import iz XML fajla sa metapodacima u pomoćnu bazu podataka; 

• vrši se verifikacija učitanih podataka: 

o proverava se da li učitani podaci ispunjavaju definisana poslovna pravila 
(učitani podaci sadrže sve šifame podatke koji su već registrovani u 
produkcionoj bazi, vreme skeniranja dokumenata nije starije od vremena 
preuzimanja dokumentacije i druge provere poslovne logike); 
o markiranje podataka koji ne ispunjavaju poslovna pravila; 
o generisanje statističkog izveštaja koji kazuje o podacima koji ne 
ispunjavaju poslovna pravila; 

o operater na osnovu generisanog izveštaja odlučuje dali su podaci iz 
privremene baze spremni za selidbu u produkcionu bazu i, ako jesu, 
pokreće ovu akciju; 

• nakon uspešne gornje akcije pokreće se kopiranje samih skeniranih podataka na 
produkcioni server; 

• uradi se rebuild i ponovna aktivacija svih index- a na najbitnijim tabelama 
Dokument i DokumentAtribut na produkcionoj bazi. 
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Zahtevi koje ovaj deo sistema treba da zadovolji jesu visoka dostupnost, pouzdanost i 
velike performanse. Dostupnost se odnosi na procenat vremena u kom je sistem 
dostupan za korisnika. Ona se postiže zaštitom sistema od padova, obezbeđivanjem 
redundantnosti sistema u slučaju padova i segmentacijom sistema. SQL Server 2008 R2 
i Windows 2008 R2 [51] nude više rešenja za ostvarivanje ovih zahteva. Database 
mirroring se koristi za kreiranje konzistentne, sinhronizovane standby baze podataka. 
Omogućava geografsku redudansu, zajedno sa enkripcijom mrežnog saobraćaja. 
Database failover jc gotovo trenutan (manje od tri sekunde). SQL Server 2008 podržava 
tri database mirroring konfiguracije: 

• asinhroni mirroring; 

• sinhroni mirroring sa automatskim failover-om; 

• sinhroni mirroring bez automatskog failover-a. 

Koristi se i Log shipping koji predstavlja proces bekapovanja transaction log -а na 
primamom serveru i njegovo kopiranje na standby server, tako da, u slučaju otkaza 
primarnog servera, standby server može da preuzme njegovu ulogu, za kreiranje 
geografski udaljene standbv baze podataka. Predstavlja jednostavno rešenje. Nedostatak 
je što se postupak oporavka ne može obaviti potpuno automatski. 

Da bi ovakav sistem odgovorio na zahteve u pogledu pouzdanosti, dostupnosti i 
perfonnansi, potrebno je vrlo precizno definisati njegove kapacitete. Planiranje 
kapaciteta predstavlja proces definisanja potrebnog hardvera koji će moći da podrži 
očekivano opterećenje sistema. Prilikom definisanja potrebnog kapaciteta sistema, treba 
obratiti pažnju na sledeće: 

• performanse koje se žele postići; 

• planirano opterećene sistema; 

• dizajn aplikacija (način pristupa podacima). 

Prilikom planiranja kapaciteta u pogledu diskova treba obratiti pažnju na sledeće: 

• izbor odgovarajućeg RAID nivoa utiče značajno na performanse prilikom 
pisanja i čitanja podataka; kod slučajnog pristupa (čitanja), najbolje 
performanse se postižu sa RAID 0 i RAID 10 nivoom; kod slučajnog upisa, 
najbolje performanse se postižu sa RAID 0 nivoom; 

• izbor RAID nivoa direktno utiče na broj ulazno/izlaznih operacija za 
transakciju; 

• broj diskova je važniji nego ukupna veličina storage- a; veći broj diskova (u 
RAID-u) može značajno da poveća performanse sistema; 

• prilikom utvrđivanja broja diskova, uzeti u obzir dve glavne komponente: 

o operativni sistem (WIN 2008 R2) i SQL Server 2008 R2; 
o baze podataka; 

o broj potrebnih diskova za baze podataka zavisi od prostora koji je 
potreban za smeštanje podataka i nivoa performansi koji se želi 
postići; prostor koji svaka baza podataka zauzima, predstavlja sumu: 

• potrebnog prostora za transaction log; 

• potrebnog prostora za podatke; 

• potrebnog prostora za indekse; 

• potrebnog prostora za privremene podatke; 
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Prilikom planiranja kapaciteta memorije treba obratiti pažnju na sledeće: 

• kod sistema za upravljanje podacima memorija predstavlja veoma bitan 
faktor; ovde važi opšte pravilo da što više memorije sistem ima to bolje 
funkcioniše; 

• minimum тетогу = (svstem тетогу) + (user тетогу) + (database process 
тетогу) 

System тетогу predstavlja količinu memorije koju zauzima OS i SQL Server. 

User тетогу predstavlja količinu memorije za sve konkurentne korisnike (oko 500 KB 
po jednom korisniku). 

Database process тетогу = log area + database cache. 

Cache size = (cache block size) * (number ofblocks in cache). 

Prilikom planiranja kapaciteta procesora treba obratiti pažnju na sledeće: 

• sistemi za upravljanje bazama podataka predstavljaju procesorski veoma 
intenzivne aplikacije; 

• na osnovu odgovarajućih parametara izračunati zauzetost (opterećenost) 
procesora; na osnovu proračunate zauzetosti, definisati potreban broj 
procesora tako da opterećenost svakog pojedinačnog procesora ne bude veća 
od definisane gornje granice (opterećenost procesora ne bi trebalo da bude 
veća od 75 %). 

Radi obezbeđivanja sigumosti podataka, potrebno je minimum jednom dnevno praviti 
backup baze. Ukoliko se poseduje neki namenski backup software može se praviti i 
inkrementalni backup. Prilikom svakog novog punjenja baze podacima, potrebno je 
napraviti /«// - backup baze, zatim napraviti restore baze radi provere backup- a i nakon 
verifikacije backup- a pristupiti učitavanju novog seta podataka. Periodično (jednom 
mesečno) testirati backup i restore plan na testnom okmženju. 

Prilikom realizacije hardverske stmkture sistema korišćeno je odgovarajuće virtuelno 
okmženje. Za postizanje maksimalnih perfonnansi baza podataka i arhivirani podaci 
(slike) su smešteni na storage- u koji je pravilno pro filisan u skladu sa zahtevim i 
načinom rada aplikacije. Za mrežno povezivanje obezbeđena su dva interfesja od lGb/s 
koji su povezani u „team” čime bi se obezbedila veća pouzdanost i dostupnost sistema, 
kao i veći mrežni protok. 

Za potrebe rada aplikacije su obezbeđeni serveri sledećih karakteristika: 

Hardware. 

• CPU - 2 jezgra sa min 2GHz x64; 

• RAM-16GB; 

• HDD - 40GB za instalaciju operativnog sisitema SQL-a (prostor za bazu i 
smeštanje podataka, potrebnio je obezbediti dovoljno prosotora u skladu sa 
veličinom arhiva uz definisanje adekvatne rezerve za budući rast); 

• Network- 2 х lGb/s interfejs. 

Sistemski softver. 

Win. server 2008 R2 SE - x64, SQL server 2008 R2 SE, x64, Lamp server 1.7.3 
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Slika 149. Dijagram baze podataka sa ključevima i bez predstavljanja atributa 
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6.6.2.5 Fizička arhitektura klirinške kuće 

Sistem je realizovan sa Hewlet Packard, APC i Cisco hardverskim komponentama. Na 
osnovu proračuna i procene ustanovljena je hardverska struktura koja bi u potpunosti i 
na optimalan način zadovoljila potrebe sistema. Predloženi sistem se sastoji od tri 
podsistema: Produkcionog sistema, Rezervnog sistema i Testnog sistema, što u 
potpunosti zadovoljava stroge uslove sistema u finansijskoj industriji. Sistem je 
realizovan da bude izbegnuta pojava single point of failure na pimarnoj i rezervnoj 
lokaciji. Testni sistem ima zadatak za proveru funkcionalnosti komponenata sistema 
tokom životnog ciklusa produkcionog sistema. 

Na slici 150. predstavljena je jedna od mogućih realizacija Produkcionog sistema. Pored 
ove, moguće su i druge fizičke realizacije sistema, što zavisi od poslovne politike 
vlasnika i propisanih sistemskih normi. Radne stanice koje pristupaju portalu sistema za 
administraciju i monitoring nalaze se u posebnoj demilitarizovanoj zoni. Fajl adapter se 
nalazi u istoj demilitarizovanoj zoni koja na slici nosi naziv Workstations. Banke koje 
pristupaju sistemu su na komunikacionoj infrastrukturi u zoni koja je na slici nazvana 
Outside što treba da označi da se svi korisnici koji pristupaju na taj način smatraju 
potencijalno opasnim po sistem. 

U posebnoj demilitarizovanoj zoni Inside 2 nalaze se aplikativni serveri koji su od 
ostalog dela sistema odvojeni firewall-o m na kome je postavljana maksimalna moguća 
zaštita. Transportne komponente su smeštene na servere Transport 1 i Transport 2 zbog 
svoje specifične uloge primopredaje sadržaja u dve zone. Prema spoljašnosti su u 
DMZl u koju mogu da se prime poslati fajlovi iz Outside zone a prema DMZ2 sa 
drugim komunikacionim resursima vrši se predaja sistemu. Na taj način se postiže filter, 
koga je veoma teško proći, pošto je jedini sadržaj koji može da prođe verifikovana i 
autorizovana adresibilna poruka koja sadrži poslovnu logiku. U najzaštićenijoj zoni 
nalaze se sistemi za procesiranje i skladištenje, kao i ostali pomoćni sistemi 
(redundantni domen kontroleri, certifikaciono telo i nodovi prema testom, rezervnom i 
sajtu u slučaju nemogućnosti rada primamog sajta u katastrofalnim uslovima). Disaster 
sajt ima posebno planiranu komunikacionu i serversku infrastmktum. 

Sistem za kliring čekova [215] pušten je u produkciju 09.05.2005. godine i prve godine 
u radu imao je zero downtime, što dodatno potvrđuje visokopouzdan i efikasan rad 
sistema. 

Iz svega iskazanog sledi da se realizacija SEPA platnog sistema, recimo za Credit 
Transfers, korišćenjem navedenih standardnih komponenata sistema, sa stanovišta 
procesiranja pomka, uz korišćenje odgovarajućih definisanih ISO 20022 šema se svodi 
na definisanje PDWF i DDF specifikacija koje opisuju Credit Transfers po 
dokumentima: 

• SEPA CREDIT TRANSFERS, SCHEME ROOLBOOK, Doc: EPCl25-05 
(Version 2.0. Approoved); 

• Credit Transfers and Direct Debits, Messge Flows UNIFI (ISO 20022), July 
2006.; 

• Pavments Standards - Clearing and Settlement, UNIFI (ISO 20022) Message 
Definition Report (Approved by UNIFI Pavment SEG on June 2006. - Edition 
July 2006.). 
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Slika 150. Moguća struktura i međuzavisnost 
hardverskih komponenata produkcionog sistema 

Sa stanovišta ostalih elemenata sistema, sprovedena je standardna procedura 
implementacije potrebnih resursa. Ukoliko je već postojala implementacija nekog 
drugog SEPA platnog sistema (recitno Direct Debit ili implementacija SEPA Cards 
Frameworka ), onda je samo potrebno izvršiti eventualnu dopunu resursa (na primer 
hardverski - servera zbog moguće ili željene povećane potrebe procesorske snage) i 
implementirati komponente Credit Transfersa. Isto tako moguća je implementacija e- 
invoicinga kada budu bili u SEPA programu. 

Polazišta od kojih se utvrđuje SEPA kompatibilnost dati su u Prilogu 7: „Ispunjenost 
EPC regulative“, kao i ispunjenost osnovnih principa banke za tneđunarodna poravnanja 
(BIS) koje sistematski važni sistemi moraju da ispune i koji su dati u Osnovnim 
principima za evro platne sisteme na malo. 

Prilikom realizacije klase SEPA platnih sistema, dobija se niz komplementamih 
prednosti, standardizovan razvoj i interoperabilnost elektronskog poslovanja platnih 
sistema. 

6.7 Analiza postignutih rezultata modelom 

Za platne sisteme u Srbiji od izvanrednog značaja je interoperabilnost sa globalnim 
međunarodnim standardima. Do sada su razmatrani samo aspekti sa stanovišta 
finansijske industrije, međutim, postoje i dmgi, sa stanovišta IT industrije. 
Kvalifikacijom platnih sistema, koji su izrađeni od strane domaćih IT kompanija, u red 
kompatibilnih sa svetskim standardima, umnogome se povećavaju izvozne šanse na 
globalno tržište. To je od izvanrednog značaja za prodor domaćih ideja u oblasti IT 
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industrije van naših granica. Do sada nije bilo nikakvih ispoljavanja naše IT industrije u 
tom smislu, a pretpostavka je da u tom domenu struktura IT eksperata sa našeg područja 
ima šta da prikaže. Kvalifikacija domaćih platnih sistema kao kompatabilnih sa 
globalnim standardima ima još jedan aspekt koji je od velikog značaja. On se odnosi na 
pružanje usluga procesiranja subjektima u regionu, ali i šire. Na taj način, koristeći 
svoje geopolitičke prednosti, industrijski segment koji bi se bavio procesiranjem zauzeo 
bi značajno mesto u društveno-ekonomskom pogledu. Ukoliko bi došlo do takve 
afinnacije, razmere efekta bi se mogle meriti sa onim koji ima tradicionalno bankarstvo 
u Švajcarskoj, automobilska industrija u Nemačkoj i slično. Potrebno je naglasiti da 
prodor u IT sektor koji se bavi sistemima finansijske industrije nije lak. I vremenski je 
relativno dug. Na osnovu iskustava uspešnih svetskih kompanija, put do uspeha u tom 
domenu meri se decenijama. 

Generalni aspekti koji čine interoperabilnom SEPA klirinšku kuću Udruženja banaka 
Srbije - Klirinšku instituciju banaka jesu: 

• izgrađen je platni sistem nad adekvatnim skupom ISO standarda; 

• sistem se uklapa u SEPA viziju; 

• sistem se uklapa u SEPA Deliverv Plan (EPC timing and milestones); 

• dobija se mogućnost pouzdane izgradnje adekvatne infrastrukture nakon 
uspostavljanja celokupnih normativa određene oblasti u finansijskoj industriji 
što je jedan od postulata EPC-a; 

• data je mogućnost izbora isporučioca IT podrške u smislu koji promoviše EPC 
(Promotion of the optimal balance between cooperation and competition ); 

• minimiziraju se ulaganja kod korisnika u adaptiranje ili migraciju; 

• postoji mogućnost potpune pokrivenosti tržišta plaćanja; 

• postignuta je IT transparentnost u odnosu na finansijski sistem koji se želi 
realizovati; 

• prirodna i adekvatna raspodela rola i odgovomosti za delove finansijskih sistema 
u okvim kompaktnih celina determinisanih zakonskim nonnama; 

• velika prilagodljivost sistema za procesiranje bazirano na transportnom sistemu, 
DDF, PDWF i BizTalk- u sa A4SWIFT-om; 

• sistemi za transport i procesiranje ostavljaju mogućnost za buduću nadgradnju 
koja zavisi isključivo od opcija implementacije i stepena razvoja tehnologije; 

• mogućnost prenosa tehnologije prostim prenosom adekvatnih standardnih znanja 
iz propisanih oblasti; 

• mogućnost uvođenja inovacija u finansijskoj industriji. 

Elementi interoperabilnosti kod transporta poruka 

Adekvatna transportna infrastmktura uopšte, u svim privrednim oblastima je osnova na 
kojoj mogu da se grade uspešni i produktivni sistemi. Transportnu infrastrukturu u 
oblasti finansijke industrije predstavljaju sistemi koji su sposobni da na siguran, 
bezbedan, neporeciv, lak, brz i jeftin način prenesu finansijske informacije sa jedne 
tačke finansijskog polja na dmgu tačku. Izgrađeni sistem ima sledeće elemente SEPA 
kompatibilnosti: 

• izgrađen je vlasnički transportni sistem za prenos determinisanih pomka; 

• izgrađeni vlasnički transportni sistem u sebi sadrži sve potrebne elemente za 
međusobnu komunikaciju između supersistema i subordinate sistema na 
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standardnim resursima koji obezbeđuju mogućnost komunikacije, kao i 
mogućnost korišćenja mobilne i satelitske komunikacione infrastrukture; 

• transportni sistem obezbeđuje i rutiranje poruka po zadatim šemama za rutiranje 
poruka; 

• transportni sistem sadrži mogućnost izgradnje simetričnih i asimetričnih 
codera/decodera koji obezbeđuju različite procese potrebne prilikom transporta 
poruke kod sendera/receivera ; 

• transportni sistem je obezbeđen savremenim sistemima za bezbednost i zaštitu 
kanala i podataka; 

• sistem za bezbednost i zaštitu podataka omogućio je višestepeno potpisivanje 
sadržaja u odnosu na vlasništvo nad podacima kao i u odnosu na role u sistemu; 

• transportni sistem omogućio je LEGO efekat, što ga čini visokopristupačnim u 
izgradnji mreža za transport poruka, ali i adaptivnim u odnosu na okolnosti koje 
mogu da nastupe u toku produkcije (geopolitičke izmene, organizacione izmene, 
strukturne promene sistema); 

• transportni sistem nije zavisan od bilo koje strukture (vlasničke strukture, 
geopolitičke i ostalih mogućih struktura), zavisan je jedino od organizacione 
strukure koju propisuje nadležni organ (SEPA, centralna banka države, banka); 

• mogućnost izgradnje novih korporativnih, bankarskih, centralno bankarskih, 
državnih i međudržavnih transportnih mreža sa odgovarajućim centrima za 
procesiranje, ali i integraciju adekvatnih postojećih sistema; 

• mogućnost komunikacije entiteta sa nodovima sistema, kao i entiteta 
međusobno, bez obzira na nacionalnu pozicioniranost ali u okvirima koje zadaju 
odgovarajući odgovorni autoriteti predmetne oblasti. 

Elementi interoperabilnosti kod pretprocesiranja i procesiranja 

Sistemi za procesiranje zadovoljavaju sledeće elemente SEPA interoperabilnosti: 

• koriste se definisane SEPA šeme ili adaptirane custom šeme uz adekvatnu 
konverziju u odnosu na ciljni sistem ( receiver ); 

• moguća je izgradnja dodatnih logičkih podsistema zadate namene koji 
zadovoljavaju posebne aspekte ili lokalne osobenosti, što je izričit zahtev za 
kompatibilnost; 

• sistem za procesiranje omogućava efekat slagalice što ga čini adaptivnim u 
odnosu na okolnosti koje mogu da nastupe u toku produkcije (definisanje novih 
primena sistema, promena namene ili dopuna fu nk cionalnosti realnog sistema); 

• mogućnost adaptiranja sistema na ostale regionalne/lokalne sisteme za 
procesiranje. 

6.7.1 Eksperiment u klirinškoj kući 

Postavljeni zadatak za eksperiment: napraviti fizički model sistema (prototip) koji će 
dokazati da je moguće izgraditi sistem baziran na standardnim adresibilnim porukama, 
koji sadrži i elemente izrađene različitim vrstama alata prisutnim na tržištu, kao i javno 
dostupnim alatima koji su izrađeni za specijalnu namenu, za potrebe izvršavanja poruka 
više sistema, određenim jednim standardom: kredit transfer (u realnom veremenu ili 
odložen) i direct debit, odnosno tri sistema u jednom: RTGS, credit transfer i direct 
debit; sistem izvesti jednom porukom, a potrebno je opisati i sve prateće poruke koje iz 
osnovne poruke proističu. 
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Opis rešenja: Banka šalje poruke sa odgovarajućom naznakom u tagu 113 bloka 3. 
Ukoliko je tag 113 manji od 0100, onda poruka pripada RTGS sistemu i to tako da, 
ukoliko je vrednost između 0050 i 0100, poruka se odbija ukoliko nema sredstava za 
izvršenje; ukoliko je vrednost taga 113 manja od 0050, onda se poruka smešta u red za 
čekanje dok se ne steknu uslovi za njeno izvršenje ili do njenog opoziva. Ukoliko je 
vrednost taga 0100, onda je poruka kreditna i pripada kliring sistemu, a njeno izvršenje 
se obavlja po pravilima kliringa. Ukoliko je vrednost tag 113 jednaka 0101, onda je 
poruka debitna i pripada kliring sistemu, a njeno izvršenje se obavlja po pravilima 
kliringa. Nizovi „{ 1 :F01“, ,,{3:“, ,,{4:“ su oznake blokova. Tag „:20:“ je 

referenca poruke, a u tagu „:23:“ je oznaka da li je transakcija inicirana od korisnika 
sredstava ili od dužnika. Ukoliko je vrednost ovog taga CREDIT inicijator transakcije je 
dužnik. Tag „:21:“ predstavlja referencu transakcije u okviru poruke, a tag „:32В:“ 
iznos transakcije u okviru instrukcije, dok tag „:32А:“ predstavlja sumu transakcija. 
Tagovi „:26Т:“, „:71А:“ imaju konstatne vrednosti u slučaju standarda u Republici 
Srbiji. Ostali elementi prva tri bloka su po pravilima NBS. Kod prva dva primera imamo 
da su tagovi „:50К:“ - račun nalogodavca (dužnika), „:59:“ - račun korisnika, a u sva tri 
primera da su tagovi „:53А:“, odnosno „:54А:“ računi banke nalogodavca, odnosno 
banke korisnika. Kod trećeg primera imamo da tagovi „:50К:“ i „:59:“ sadrže 
informacije o računima nalogodavca i klijenta. 


Primeri realnih poruka primenjenih u ekserimentu 


Primer 1: MT102 real time („brza dvojka“ Narodne banke Srbije) 

{1:F01KOBBRSBGAXXX1234123456} {2:1102NBSRRSBDX1PSN} {3:{113: 0030}} {4: 

:20:8921600003495641 

:23:CREDIT 

:26T:REF 

:71A:SHA 

:21:08700081623194 
:32B:RSD2083,33 
:50K:/160000000000734948 
Jedinstvo d.o.o. 

DUNAVSKA 15 
Kladovo 

:59:/205000000002006630 
STR KOMISION XXL 
Beograd 
:70:SIF-241 

:77B:Obustave iz zarada 
:32A:100112RSD2083,33 
:53A:/D/908000000001600187 
DBDBRSBG 

:54A:/908000000002050170 

KOBBRSBG 

-} 
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Primer 2: MT102 credit transfer 

{1 :F01SBPORSBGAXXX1234123456} {2:1102NBSRRSBDX1PSN} {3: {113: 0100}} 

:20:8921600003495772 

:23:CREDIT 

:26T:REF 

:71A:SHA 

:21:08700081658015 

:32B:RSD20000,00 

:50K:/160000000004209779 

RADNJA DOO 

GOSPODARA VUCICA 45 

Beograd 

:59:/200004350010200082 
JP PTT SRBIJA 
BEOGRAD 
:70:SIF-221 

PBO-974210111180000811 
:77B:Avans za postanske usluge 
:32A:100112RSD20000,00 
:53A:/D/908000000001600187 
DBDBRSBG 

:54A:/908000000002000118 
SBPORSBG 

-} 


Primer 3: MT102 direct debit (kliring čekova) 

{1:F01KUBKRS22AXXX1234123456} {2:1102NBSRRSBDXIPSN} {3: {113: 0101}} {4: 

:20:890335000964511c 

:23:CHQB 

:26T:REF 

:71A:SHA 

:21:668145 

:32B:RSD2350,00 

:50K:/908000000003250157 

NONAME 

:59:335000000000377388 

STR KOMISION, JOVIIC JANKO 

:70:SIF-283 

PBZ-0000004243101 

PBO-1705073351700 

REF- 

:77B:ISPLATA PO CEKU 
NON 

TRN-0300100010929 
:32A:070517RSD2350,00 
:53A:/C/908000000003350164 
MBSORS22 

:54A:/D/908000000003250157 

KUBKRS22 

:72:/BNF/ 

-} 
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Navedeni eksperiment je izveden na prototipu koji je prikazan na Tehničkom fakultetu u 
Novom Sadu. 

Posledice rezultata eksperimenta su sledeći: 

• uvedena je real time transakcija u RTGS sistem u Srbiji korišćenjem MT102 
poruke koja je standardom predviđena za kliring, odnosno odloženo izvršenje; 

• kliring čekova se obavlja porukom MT102 za credit transfer je direct debit 
sistem jer transakcije inicira poverilac, pa samim tim ima mogućnost da 
procesira i credit transfer poruke; 

Adaptacijom sistema za kliring čekova uvođenjem još jedne klase operacija u sistem, 
dobija se mogućnost procesiranja i real-time transakcija posredstvom RTGS sistema 
Narodne banke Srbije. 

6.7.2 Rezultati empirijskih merenja 

Laboratorijska merenja na podsistemu za razmenu poruka i podsistemu za procesiranje 
pokazala su da mogu da zadovolje različite zahteve u odnosu na sposobnost 
komunikacionog kanala i broja transakcija koje sistem treba da obradi. 

Prvo su vršena merenja koja bi pokazala zavisnost performansi od broja udaljenih 
korisnika. Pokazalo se da je uticaj na performanse pet udaljenih korisnika koji 
istovremeno konstantno šalju poruke sa finansijskim transakcijama veličine 10 kb kroz 
Frame Relay link od 64 kb/s prema centralnoj lokaciji manji od 3%. Sa 25 udaljenih 
korisnika uticaj na performanse sistema nije se drastično povećao, do 5% smanjenja 
performansi. Na 40 udaljenih korisnika procenat uticaja na performanse sistema 
povećao se ali je poraslo procesorsko zauzeće servera na centralnoj lokaciji. 
Dodavanjem još jednog servera na centralnoj lokaciji za procesiranje uticaj na 
performanse vratio se na pogoršanje perfonnansi za 5%. Poboljšanjem komunikacione 
sposobnosti Frame Relav komunikacione infrastrukture povećao se obrađeni broj 
transakcija, ali su odnosi ostali približno isti. Isti rezultat je postignut i uvođenjem po 
pet korisnika sa komunikacionom sposobnošću od 4 kb/s, 16 kb/s, 32 kb/s, 64 kb/s i 128 
kb/s. Rezultati navode na zaključak da se dodavanjem servera na centralnoj lokaciji 
može rešiti pad performansi procesiranja, a da se povećanjem komunikacionih 
kapaciteta rešava problem željenog broja finansijskih transakcija. Posebno je potrebno 
navesti da je vrednost finansijskih transakcija već sa jednim udaljenim korisnikom 
dostizala monetarne kapacitete snažnijih monetamih sistema sa Real Time 
transakcijama u vremenskom periodu od osam radnih sati sistema. Republika Srbija 
dnevno retko prelazi 1.000.000 Real Time i odloženih transakcija. Naknadno opisana 
merenja vršena su sa jednom udaljenom stanicom i jednim serverom na centralnoj 
lokaciji da bi se videla sposobnost sistema za prenos i procesiranje pomka. Ogled koji je 
nadalje vršen podrazumevao je sledeće: potpisivanje pomke na udaljenoj lokaciji i 
slanje potpisane pomke sa prijemom ACK/NAK pomke, na centralnoj lokaciji prihvat 
pomke, proveru potpisa, pripremanje i vraćanje ACK/NAK pomke, skladištenje pomke 
u centralnu bazu podataka, parsiranje i proveru finansijske transakcije (semantiku 
pomke i provem poslovnih pravila), skladištenje finansijske transakcije u bazu podataka 
za procesiranje, formiranje, potpisivanje i slanje pomke prihvatanja na obradu i pomke 
sa rezultatima obrade, kao i formiranje, potpisivanje i slanje pomku drugoj strani u 
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finansijskoj transakciji. Za inicijalizaciju poslovnog procesa korišćena je hibridna 
MT102 (Real Time) poruka ISO15022 standarda. 



-*-FR32kbps -*-FR64kbps_ FR 128 kbps_FR 512 kbps 


Slika 151. Zavisnost broja transakcija u poruci i propusnog opsega (msg/h) 

Slika 151. daje prikaz zavisnosti broja poruka, broja finansijskih transakcija (FT) u 
porukama u odnosu na propusnu moć komunikacionog kanala. Apscisa je broj 
finansijskih transakcija po poruci, ordinata je broj poruka na sat (msg/h). Jasno je da je 
broj prosleđenih poruka proporcionalan kapacitetu komunikacionog kanala, bez obzira 
na veličinu poruka. Pri prosleđivanju poruka sa manjim brojem transakcija razlika u 
broju poruka je veća nego pri prosleđivanju poruka u kojima je pakovan veći broj 
transakcija u zavisnosti od propusne moći kanala. Jasno je da, iako je manji broj poruka, 
veći je ukupan broj finansijskih transakcija ukoliko je pakovano više finansijskih 
transakcija po poruci, i da je veći stepen iskorišćenja kanala ukoliko poruke sadrže više 
finansijskih transakcija. Na apscisi je dat i prosečan broj finansijskih transakcija za 
svaku veličinu poruke. Povećanjem broja transakcija po poruci, do određene granice, i 
povećanjem komunikacione sposobnosti kanala postiže se optimalni kapacitet potreban 
za razmenu elektronskih dokumenata. Na slici 152. na ordinati je prikazan broj poruka 
na sat i prikazano merenje u odnosu na veličinu poruke i komunikacionu sposobnost 
kanala. 



—•— FR32kbps —•— FR64kbps_FR 128 kbps —*-FR 512 kbps 


Slika 152. Količina transportovanih finansijskih transakcija (FT) 
u zavisnosti od propusnog opsega i veličine poruka 

Na slici 153. izdvojeni su rezultati šest merenja sa porukama sa fiksiranih 100 FT i 130 
FT u zavisnosti od propusnog opsega komunikacionog kanala. Apscisa je 
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komunikaciona sposobnost kanala, a ordinata broj finansijskih transakcija na sat (FT/h). 
Pakovanjem od 130 FT na komunikacionom linku od 512 kb/s u toku jednog sata 
izmereno je oko pola miliona FT. 



Slika 153. Količina transportovanih finansijskih transakcija 
u zavisnosti od veličine i propusnog opsega FR (FT/h) 

Rezultati merenja na slikama 151. - 153. poslužili su bankama u Srbiji da odrede kakve 
kapacitete komunikacione infrastrukture treba zakupiti za poslove sa klirinškom kućom. 

6.7.3 Statistika rada sistema Udruženja banaka Srbije 

U ovom poglavlju je prikazana statistika rada sistema „Serbian Clearing House“ u 
produkciji. Statistika je prikazana u RSD (dinarima Republike Srbije), dok je autor ovog 
rada bio odgovoran za njegovo funkcionisanje. 

Broj transakcija u toku prve godine (od 09.05.2005. do 09.05.2006.) posle nove godine 
izašla je nova zakonska regulativa koja je ograničila upotrebu čekova za odloženo 
plaćanje na više meseci. Otuda i pad u 2006. godini, prikazan na slici 154. 
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Slika 154. Broj finansijskih transakcija po godinama 

Slika 155. pokazuje odnos finansijskih transakcija po finansijskom obimu i u odnosu na 
sliku 156. Nije toliko izražen pad u 2006 godini jer je srednja vrednost transakcije 
očigledno povećana i na taj način ublažen zakonski okvir koji je smanjio broj 
finansijskih transakcija. Na slici 155. vidljivo je da se u poslednje tri praćene godine 
iznos transakcija gotovo izjednačio u obimu u odnosu na prvu godinu rada sistema. 
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Slika 155. Iznos u RSD transakcija sa čekovima po godinama 

Na slici 156. prikazan je rad u prvih 12 meseci rada sistema. Vidi se drastičan pad 
realizovanih finansijskih transakcija od meseca januara 2006 godine i da je broj 
transakcija, uvođenjem nove zakonske regulative, sveden na trećinu. 



Slika 156. Broj čekova u prvih 12 meseci rada sistema 

Slika 157. prikazuje da je do pada u finansijskom obimu transakcija na trećinu došlo u 
periodima decembar 2005. godine i januar 2006. godine i da je u januaru sveden na 
trećinu. 
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Slika 157. Iznos u RSD transakcija sa čekovima u prvih 12 meseci rada 

Sistem je projektovan da ubrzo nakon puštanja u produkciju za kliring čekova preuzme 
optimalno i dnevno oko 250.000 finansijskih transakcija - platnih naloga čija vrednost 
ne prelazi 5.000 RSD. Pošto se to u međuvremenu nije desilo, u produkciji je sistem bio 
uposlen samo 3%. Da je sistem bio optimalno korišćen od puštanja u produkciju od 
09.05.2005. do 31.12.2010., broj finansijskih transakcija bio bi 817 miliona sa 
finansijskom vrednošću oko 2.500 milijardi RSD. Projektovani maksimalan broj 
finansijskih transakcija koje sistem može da obradi iznosio bi oko dve milijarde u 
navedenih šest godina a očekivana vrednost finansijskih transakcija bila bi oko 6.000 
milijardi RSD (tabela 22.). 


UBS KIB 

(od 05.2005 do 12.2010) 

Procenat 

projektovanog 

kapaciteta 

Broj finansijskih 
transakcija 
(u milionima) 

Finansijska vrednost 
transakcija 
(u milionima RSD) 

Uposlenost u produkciji 

3% 

61 

182,772 

Optimalni kapacitet 

40% 

817 

2,436,955 

Maksimalni kapacitet 

100% 

2041 

6,092,388 


Tabela 22. Statistika klirinške kuće Udruženja banaka Srbije* 

(* Objavljeno od strane Udruženja banaka Srbije na izlaganju na bankarskom skupu Banklnfo 2006 na Paliću) 


6.7.4 Simulaciona analiza 

Testiranje transportne komponente i sistema za pretprocesiranje, procesiranje i 
postprocesiranje vršeno je simulacijom sistema, zbog potrebe da se odredi garantovana, 
potrebna i dovoljna brzina (propusni opseg) linka za prenos SWIFT poruka koji 
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pojedinačne banke trebaju da zakupe prema Klirinškoj instituciji banaka - KIB-u, 
propusnog opsega i sistema za obradu u KIB-u. 

Za potrebe testiranja korišćena su dva računara i FR link. Računari su simulirali 
klijentsku (banke) i serversku (KIB) stranu sistema. FR link su simulirali par Cisco 805 
routera uvezanih back-to-back. Na taj način je dobijen kontrolisani propusni opseg. 
Testiranje je vršeno za različite veličine poruka (broj čekova u poruci) i različite 
propusne moći linka. Na početku testa ustanovljeno je da i za najveće kapacitete linka 
prema KIB-u sistem za obradu KIB-a može da procesira u realnom vremenu i da test 
može da se nastavi samo menjanjem parametara sistema za transport poruka. Testiran je 
transport poruka male dužine (od 1KB do 8KB) i poruka srednje dužine (24KB i 
32KB).Testirani su sledeći parametri transporta: 

• broj prenetih poruka u toku jednog sata; 

• količina prenetih poruka (u MB) za vreme od jednog sata. 

Pojedinačni rezultati testa predstavljeni su u dokumentu o redovnom testiranju 
transportne komponente, sa obeleženim mestom, datumom i vremenom testiranja, kao i 
sa potpisom izvođača testa i rukovodioca projekta. 

Početni uslovi testa specificirani su server i klijenti, kao i specifikacija odgovarajuće 
komunikacione infrastrukture: 

• Server: Celeron 1.8 GHz; 1.00 GB RAM; 

• Client: Pentium III 1.2 GHz; 256 MB RAM; 

• FR 32 KBPS; 

• HTTPS. 

Specificirani parametri svakog pojedinačnog testa su: 

• br. čekova; 

• br. poruka; 

• br. ciklusa; 

• veličina poruke u KB. 

Beleženi su očekivani rezultati testa, tok testiranja sa vremenom početka i vremenom 
završetka svakog pojedinačnog testa, kao i rezultati svakog pojedinačnog testa po 
pitanju vremena potrebnog da se opit izvrši, kao i veličini materijala, odnosno podataka 
koje je potrebno transportovati sa klijentskih radnih stanica, pretprocesirati, procesirati i 
distribuirati sve potrebne odgovore za zahtevane transakcije. Zaključak se sastojao od 
brzine obrade u broju poruka, odnosno transakcija na sat, kao i veličine postignutog 
opsega procesiranja u megabajtima. 

Kako bi dobijeni rezultati bili što pregledniji, podaci su smešteni u tabele i predstavljeni 
graficima. Sastavljena su dva dokumenta. Prvi dokument predstavlja tabelame rezultate 
testiranja za pomke male dužine u serijama velike dužine (1000 pomka). Dmgi 
dokument predstavlja tabelame rezultate testiranja pomka srednje dužine u velikim 
serijama (2000 pomka). 
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Na osnovu testiranja i predstavljenih rezultata i graiika, može se jednostavno odrediti 
potreban propusni opseg linka u zavisnosti od iskazanih potreba finansijskih institucija. 

Iz rezultata testova se vidi da je moguć izbor iz spektra mogućih linkova u odnosu na 
način na koji banka predviđa da pakuje svoje poruke (broj čekova po poruci) i 
mogućnost izbora FR linkova u odnosu na kvalitet usluga u odnosu na cenu koju KIB 
želi da ponudi bankama. 

Rezultati testova naživo (u realnim uslovima) iz banaka prema KIB-u na realnom FR 
linku pokazali su sledeće: 

1. prilikom testiranja jedne banke na FR 64 kbps (LHB banka) dobijeni su 
sledeći rezultati : brzina transporta je preko 10.000 poruka srednje dužine (80 čekova u 
poruci) u toku jednog sata; 

2. prilikom testiranja dve banke na FR 64 kbps (LHB banka i Delta banka) 
dobijeni su sledeći rezultati : brzina transporta je preko 15.000 poruka srednje dužine 
(80 čekova u poruci) u toku jednog sata na strani KIB-a - odnosno, po približno 8.000 
poruka iz svake banke; do rezultata se došlo tako sto su sa dve lokacije (iz dve banke) 
poslate serije poruka istovremeno i merena je brzina prijema poruka u KIB-u. 

Do rezultata 1 i 2 smo došli eksperimentalnim putem i to na linku kod koga nije 
kontrolisana propusna moć pa je u ovom slučaju zbog stanja na FR mreži dozvoljavana 
maksimalna moguća propuusnost od strane Telekoma. 

Rezultat testa je preporuka bankama za angažovanje FR linkova: 

• banke sa malim intenzitetom saobraćaja 

FR 32 kbps uz prilagođavanje slanja u vremenu i broja čekova u poruci; 

• banke sa sednjim intenzitetom saobraćaja 

FR 32 kbps uz prilagođavanje slanja u vremenu i broja čekova u poruci; 

• banke sa velikim intenzitetom saobraćaja 

FR 64 kbps uz prilagođavanje slanja u vremenu i broja čekova u poruci; 

• KIB 

na strani KIB-a preporučeno je da se uspostavljaju 2-megabitni linkovi do FR 
mreže, i to jedan više od minimalnih zahteva zbog balansiranja saobraćaja, 
redundantnosti i efikasnijeg iskorišćenja slobodnih resursa FR mreže. 

6.7.5 Implementaciona analiza 

Predloženo rešenje je implementirano u Udruženju banaka Srbije na dva sistema: 
sistema za kliring čekova i sistema direktnog zaduženja. Implementirano je na Microsoft 
platfomi i „ Sebian clearing house“ i prvo je rešenje klirinške kuće (ACH) koje je u 
svetu implementirano na Microsoft tehnologijama. U novembru 2005. godine je dobilo 
nagradu “ European Banking Technologv Award 2005 ” britanskog časopisa „ Banking 
technoIogy u , od eminentnih stručnjaka najvećih evropskih banaka i finansijskih 
korporacija: McKinsev & Сотрапу, Deutche Bank, Royal Bank of Scotland, BNP 
Paribas i JPMorgan. 

Korišćene implementacione tehnologije su: Windows operativni sistemi, Windows 
Communication Foundation Framework, Internet Information Services, MS SQL 
Server, MS BizTalk Server, Microsoft alati i razvojna okruženja. Svi alati i razvojna 
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okruženja pružaju raznovrsne mogućnosti i omogućavaju kombinovanje u realizaciji 
složenih scenarija integracije uz komforne korisničke interfejse Zaključak je da 
Microsoft tehnologije omogućavaju razvoj softverskih komponenti koje međusobno 
odlično sarađuju i da je Micrsofot platfonna pogodna zarazvoj aplikativnih sistema i 
rešenja iz oblasti elektronskog poslovanja platnih sistema. 

6.7.6 Analiza efekata primene i fleksibilnosti modela 

Analiza efekata primene i fleksibilnosti modela integracije elektronskog poslovanja 
platnih sistema obuhvata sledeće aspekte analize: 

• analiza efekata primene predloženog rešenja integracije na elektronsko 
poslovanje učesnika u procesima platnih sistema; 

• analiza zahteva rešenja u pogledu hardverske i softverske infrastrukture; 

• analiza stepena fleksibilnosti predloženog modela i mogućnosti prilagođavanja 
novim zahtevima; 

Najznačajniji efekat primene predloženog rešenja integracije elektronskog poslovanja 
platnih sistema jeste efikasnije, pouzdanije i semantički interoperabilno elektronsko 
poslovanje oslonjeno na standard ISOi\EC 15944-4 2007. Primena predloženog modela 
integracije unapređuje efikasnost elektronskog poslovanja na taj način što se 
standardizuje zadavanje, implementacija i eksploatacija u automatizovanoj razmeni 
podataka putem standardizovanih adresibilnih poruka sa poslovnom logikom. Primena 
standardizovanih komponenata je osnovni efekat primene predloženog rešenja 
integracije, što kao posledicu ima i propratne efekte. Najznačajniji propratni efekti su: 
olakšana mogućnost integracije sa drugim poslovnim sistema elektronskog poslovanja, 
standardizovano uvođenje novih funkcionalnosti i novih sistema elektronskog 
poslovanja, smanjenje angažovanja resursa na realizaciji i smanjenje angažovanja 
sredstava potrebnih za realizaciju. 

Važna osobina predloženog modela integracije elektronskog poslovanja platnih sistema 
jeste pouzdanost i skoro potpuna eliminacija grešaka tokom razmene i procesiranja 
podataka. Predloženi model podrazumeva standardizovanu razmenu podataka, 
standardizovano pretprocesiranje i procesiranje po dokumentima koja propisuje 
nadređeni sistem, a koji je u krajnjoj instanci propisan od strane jednog supersistema 
koji je u svom domenu odgovoran za pravilno funkcionisanje svih podsistema i koji je 
nadležan za propisivanje načina ažuriranja i razmene podataka. 

Predloženo rešenje omogućava semantički interoperabilno elektronsko poslovanje 
platnih sistema zasnovanih na Resurs - Event - Agent standardu ISOf IEC 15944-4 
2007, jer je bazirano na zajedničkom informacionom modelu. Zajednički informacioni 
model zasnovan je na zajedničkom modelu podataka. Zajednički model podataka 
razvijen je na bazi zajedničkog deljenog rečnika i domenske ontologije. Domenska 
ontologija je osnov za konzistentno tumačenje značenja metapodataka i vrednosti 
podataka. 

U pogledu hardverske i softverske infrastrukture, predloženo rešenje podrazumeva 
korišćenje informacione infrastrukture standardizovane arhitekture prilagodljive 
savremenim paradigmama kao što jesu infrastruktura privatnog i javnog oblaka, 
virtualizacija, razvoj rešenja agilnim metodologijama. To znači da korisnici 
predloženog rešenja nisu u obavezi da nabavljaju dodatni hardver, kao ni da kupuju 
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softverske licence, već da sigurne servise mogu pribavljati i od specijalizovanih 
procesorskih agenata. Servisno orijentisana arhitektura, na kojoj je bazirano rešenje, 
omogućava integrisanje aplikacija razvijenih na različitim platfonnama. Zaključak je da 
predloženo rešenje ne zahteva razvoj novih lokalnih aplikacija i baza podataka, već 
naprotiv - omogućava korišćenje postojećih informacionih sistema i upotrebu 
standardizovanih komponenata elektronskog poslovanja platnih sistema. 

Predloženo rešenje poseduje visok stepen fleksibilnosti i nije unapred determinisano 
brojem učesnika u integracijama elektronskog poslovanja platnih sistema. Fleksibilnost 
je osnovna karakteristika servisno orijentisane arhitekture na kojoj je ovo rešenje 
zasnovano. Kako postojeće, tako i nove lokalne aplikacije mogu koristiti ovo rešenje, 
dodavanjem reference na odgovarajući servis, inicijalizovanjem i korišćenjem servisa iz 
oblaka. 

6.7.7 Poređenje sa drugim rešenjima 

U ovom rešenju i način zadavanja sistema jasno je determinisan dokumentima opisanim 
u poglavlju 5.5. U odnosu na druga rešenja, jasno su izdvojeni transport za akviziciju i 
distribuciju podataka, pretporocesiranje i procesiranje i odnosu na te aspekte jesno 
determinisana arhitektura rešenja sa svim ostalim aspektima kao što su skalabilnost i 
redudantnost. Svaki segment modela predloženog rešenja može biti implementiran sa 
nekom od adekvatnih tehnologija i metodologja zbog standardizacije načina zadavanja i 
funkcionalnosti komponenata sistema, što nije slučaj sa drugim rešenjima. 

U poređenju sa drugim rešenjima, predloženi model je jedini koji je baziran na 
Microsoft tehnologijama, ali koji može da bude realizovan i na drugim dostupnim 
tehnologijama na tržištu. 

Predloženi model, u odnosu na druga rešenja, ima najkraći period implementacije. 
Standardni period implementacije za ovakve sisteme je od šest meseci do godinu dana, 
dok predloženi model može, pri prvoj implementaciji, da bude implementiran u roku od 
tri meseca, dok se implementacija svakog sledećeg sistema elektronskog poslovanja 
može izvesti u roku od mesec dana. 

U poređenju sa ostalim sistemima elektronskog poslovanja platnih sistema, predloženi 
model ima mogućnost da bude primenjen na jedinstvenoj strategiji organizacione 
jedinice (preduzeća, banke ili druge hnansijske organizacije, centralne banke ili 
državnog organa) radi jedinstvenog uređenja prostora elektronskog poslovanja platnih 
sistema, ali i ostalih sistema elektronskog poslovanja koji su zasnovani na 
standardizovanim adresabilnim porukama koje sadrže poslovnu logiku. 

6.7.8 Evalauacija predloženog modela interoperabilnog elektronskog 
poslovanja platnih sistema 

Liste kriterijuma za evaluaciju elektronskog poslovanja platnih sistema prikazane su u 
tabelama 15, 16 i 17, a u tabelama 23, 24. i 25. je evaulacija elektronskog polovanja 
platnih sistema na osnovu tih kriterijuma. Predloženo rešenje prevazilazi tri kategorije 
prepreka interoperabilnosti poslovnih sistema: konceptualne, tehnološke i 
organizacione. 
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Konceptualne prepreke se odnose na sintaksne i semantičke razlike infonnacija koje se 
razmenjuju, a koji se razrešavaju standardizacijom zadavanja sistema, poslovnih poruka 
i objedinjavanjem različitih modela podataka u jedinstveni ontološki domenski model. 
Tehnološke barijere se odnose na usklađivanje informacionih tehnologija, koji su rešene 
standardizacijom modela poslovnih procesa za razmenu, pretprocesiranje i procesiranje 
podataka elektronskog poslovanja platnih sistema. Organizacione barijere su rešene 
definisanjem odgovornosti i nadležnosti koje proističu iz zakonskog okvira u jasno 
detenninisanim sistemima putem dokumenata opisanih u poglavlju 5.5. 


Kriterijum 

Ispunjenost 

Interoperabilnost 

Sistemi su potpuno u stanju da komuniciraju međusobno, isključivo od 
zakonske regulative zavisi ko sa kim sme da komunicira. U komunikaciji se 
koriste standardni ili standardizovani formati podataka zasnovanih na XML- 
u. 

Modularna 

kompozitnost 

Sistem se sastoji od softverskih komponenata koje su kreirane sa 
mogućnošću za ponovnu upotrebu i deljenje. Iste komponente za iste 
funkcionalnosti se koriste u svim sistemima po nivoima, od super sistema do 
sistema za podršku elektronskom poslovanju pravnih i fizičkih lica. Svaka 
komponenta sistema se može koristiti u drugim sistemima elektronskog 
poslovanja za istu funkcionalnost. 

Pouzdanost 

Obim u kome se može očekivati da sistem obavlja svoju funkciju zavisi 
isključivo od velikog porasta obima saobraćaja - broja poslovnih poruka. 
Činjenica da je došlo do velikog neplaniranog porasta saobraćaja nije 
negativan aspekt sa stanovišta poslovanja, indikator je drastičnog porasta 
poslovnih pokazatelja, a samim tim i profita, pa je ulaganje u proširenje 
sistema pozitivan događaj. Osnovni faktor pouzdanosti je starost hardverskih 
i komunikacionih komponenata te da bi prekid rada bio minimalan, potrebno 
je planovima nabavke predvideti njihovo redovno obnavljanje. Prekidi rada 
mogu da se tolerišu ukoliko se dogodi neki na nivou meseca i to ne duži od 
nekoliko minuta, izuzev u uslovima elementarne nepogode - katastrofalnim 
uslovima kada prekid rada može da se meri satima. 

Dostupnost 

Vreme u kome je sistem spreman da obavlja zahtevane funkcionalnosti meri 
se u procentima u odnosu na prekide u radu, dostupnost sistema se meri sa 
99.99 (četiri devetke), a sistema za bruto poravnanje u realnom vremenu 
trebalo bi da bude ne manje od 99.999 (pet devetki) i bolje. 

Bezbednost 

Poruke u sistemu mogu da šalju samo učesnici registrovani od strane 
nadređenog sistema. Neautorizovane poruke u sistemu mogu samo da 
pošalju učesnici - podređeni sistemi. Svaka poruka nadređenog sistema 
smatra se autorizovanom. Ukoliko je u sistem moguće ubaciti veći broj 
neautorizovanih poruku, sistem se smatra nesigurnim. Broj pokušaja koji je 
veći od broja zadatog pravilima nadređenog sistema jeste diskvalifikujući za 
podređeni sistem i to je mehanizam za odbranu sistema od neautorizovanih 
poruka. Čak i slanje velikog broja kopija iste autorizovane poruke smatra se 
narušavanjem bezbednosti i sistem koji ih šalje diskvalifikuje se iz 
saobraćaja. Svako slanje neautorizovane poruke mora se od strane pošiljaoca 
detaljno obrazložiti nadređenom sistemu. Retail sistemi imaju mehanizme 
koji isključuju slanje neautorizovanih poruka. 

Performantnost 

Obim u kome se može očekivati izvršenje određenog broja transakcija, zbog 
skalabilnosti sistema, sa stanovišta poslovnog procesa nije ograničen. Već sa 
procesorima koji se ugrađuju u kancelarijske radne stanice postiže se 
nekoliko stotina hiljada transakcija na sat. Sistem je projektovan tako da 
može da prihvati od tri do četiri miliona finansijskih transakcija bruto 
sistema u realnom vremenu, što može da zadovolji RTGS sistem Narodne 
banke Srbije u narednom petogodišnjem periodu. 


Tabela 23. Tehnološka evaluacija elektronskog poslovanja platnih sistema 
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Kriterijum 

Ispunjenost 

Stabilnost 

servisa 

Stabilno u dužem vremenskom okviru, broj izmena sistema u vremenskom 
okviru je mali jer se komponente sistema konfigurišu za postojeće 
funkcionalnosti, a nove funkcionalnosti se dodaju phig andplay komponentama 
sistema bez prekida rada sistema. Sve komponente sistema su redudantne i ne 
postoji single point offailure tako da postoji mogućnost da se izvrši popravka 
sistema bez prekida rada. 

Nezavisnost 

Nezavisnost od domena primenom izolovane aplikativne logike koja se odnosi 
na opšte funkcionalnosti, čime se postiže nezavisnost od domena primene. Broj 
različitih primena zavisi isključivo od broja poslovnih sistema elektronskog 
poslovanja na koje se primenjuje; izvršena je izolacija aplikativne logike i 
primena poslovnih pravila koje su parametri sistema, dok je količina direktno 
implementirane logike samo na komponentama za koje je to neophodno zbog 
postizanja performansi sistema. Sistem, osim primene za elektronsko 
poslovanje platnih sistema, ima primenu i u drugim sistemima koji su bazirani 
na standardizovanim adresabilnim porukama koje u sebi sadrže poslovnu 
logiku. 

Proširivost 

Lako za dodavanje, modifikaciju, zamenu, uvećanje, izmenu ili pripajanje 
fimkcionalnosti jer se za izmene vrši u najvećem broju slučajeva podešavanjem 
konfiguracionih parametrara. U ostalim slučajevima se vrši dodavanje 
fimkcionalnosti komponentama za čiju primenu nije potrebno vršiti prekid rada 
sistema. Dodavanje novi komponenata baze podataka vrši se u odnosu na novu 
verziju poruka koje se primenjuju u sistemu kreiranjem novih objekata, stari 
objekti ostaju da žive u neizmenjenom obliku dok god je važeća verzija poruka 
koje sistem podržava. Proširivanje sistema u smislu povećanja moći 
procesiranja vrši se dodavanjem hardverskih komponenata na način kako je to 
predviđeno fizičkom arhitekturom sistema pošto su komponente sistema 
skalabilne. Zbog navedenih prednosti sistema, cena izmena na sistemu je 
minimalna. 

Primenljivost 

Funkcionalnosti sistema su determinisane dokumentima sistema opisanim u 
poglavlju 5.5., cena primene.je izuzetno niska jer se podešavanje sistema vrši 
kroz konfiguraciju parametara, a broj primena zavisi od broja standardizovanih 
poslovnih sistema koji su determinisani dokumentima sistema. Cena u odnosu 
na broj aplikativnih primena i količina potrebnih resursa za primenu smanjuje 
se brojem podržanih poslovnih sistema elektronskog poslovanja. Ukupna cena 
resursa za primenu sa licencama je reda veličine pola miliona evra po sajtu 
(primarni sajt, back up sajt, dizaster sajt). 

Skalabilnost 

Sistem je lak za skaliranje, poslovi oko skaliranja se svode na osnovne 
administrativne i manipulativne radnje čime se broj transakcija koje mogu biti 
prihvaćene od strane sistema može umnogostručiti. 

Ekonomičnost 

Troškovi razvoja i održavanja su niski i raspoređeni kroz vreme, u zavisnosti od 
načina puštanja servisa i ekonomskih prinosa u eksploataciji, te se na taj način 
može rasporediti u vremenskom periodu. Prilog 8. pokazuje ekonomsku 
isplativnost u odnosu na broj poruka koje su direktno proporcionalne sa brojem 
puštenih servisa sistema 


Tabela 24. Poslovna evaluacija elektronskog poslovanja platnih sistema 
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Kriterijum 

Ispunjenost 

Sekvencijalnost 

Poruke se mogu slati samo u sledu. Poruke se šalju onim redom kojim se 
kreiraju, prihvataju onim redom kojim se šalju, pretprocesiraju onim redom 
kojim se primaju i procesiraju onim redom kojim se pretprocesiraju 

Originalnost 

Poruka koja je prihvaćena pravilno je potpisana, poruka koja je prihvaćena 
neizmenjena je i zabeležena bez obzira da li je ispravna 

Kapacitivnost 

Po pitanju transporta, moguće je procesirati šestostruki dnevni obim u toku 
jednog sata. Moguće je procesirati dnevni obim u toku jednog sata, a po 
pitanju distribucije u transportu moguće je procesirati trostruki dnevni obim 
u toku jednog sata 

Sledljivost 

Registraciono telo zadovoljava kriterijum prijema, obrade i slanja svih 
zahteva - kao da se za svaku promenu (poruku ili transakciju) zahteva i 
odgovarajući izveštaj i o poruci i o transakciji. Moguće je dobiti odgovor na 
sve zahteve o svimporukama i transakcijama 

Jednostavnost 

Jasno i lako za upotrebu. Jednostavnost u upotrebi ogleda se i u činjenici da 
je dovoljno da korisnik može odgovarajućim alatom da proizvede fajl sa 
standardizovanom adresabilnom porukom koja sadrži poslovnu logiku koji 
se spušta u sistem foldera 


Tabela 25. Korisnička evaluacija elektronskog poslovanja platnih sistema 

Na osnovu prethodnog može se konstatovati da je definisani metod integracije 
interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama 
primenljiv i da je model efikasan. 
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7 Naučni i stručni doprinosi 

Najznačajniji doprinos ove disertacije ogleda se u razvoju modela interoperabilnog 
elektronskog poslovanja platnog sistema zasnovanog na standardizovanom ontološkom 
modelu podataka i procesa u poslovno orjentisanoj arhitekturi koji poboljšava 
perfonnanse poslovnih procesa. Originalnost se ogleda u definisanju metodološkog 
okvira modeliranja i integracije platnih sistema, baziranih na standardizovanom 
ontološkom modelu podataka, procesa u poslovno orjentisanoj arhitekturi i u definisanju 
metodološkog okvira akvizicije, pretprocesiranja, procesiranja i distribucije podataka za 
finansijskc sisteme elektronskog poslovanja interoperabilnih sa ostalim elektronskim 
poslovnim sistemima. 

Kao finalni rezultat istraživanja, razvijeni model je primenjen na realnim sistemima i 
omogućava brzu i fleksibilnu interakciju putem elektronskih dokumenata u obliku 
standardizovanih poslovnih poruka, što poboljšava interakciju poslovnih procesa, 
kolaboraciju sistema koji učestvuju u poslovnim procesima i povećava pouzdanost rada 
sistema. 

Primenjeni model poboljšava mogućnosti praćenja tokova podataka i na taj način utiče 
na povećanje mogućnosti upravljanja poslovnim procesima i sistemima. 

Naučni doprinos rada ogleda se u: 

• Sistematizaciji i analizi postojećih modela koji daju rešenje za elektronsko 
poslovanje platnih sistema; 

• Definisanju metodološkog okvira standardizacije organizacije podataka i 
procesa za model interoperabilnih platnih sistema zasnovanih na ontologijama, i 
to sledećim dokumentima: Operativnim pravilima, Formatom i namenom 
poruka, Terminskim planom, Tehničkim uputstvom, Poslovnim pravilima, 
šemama i instancama poruka; 

• Definisanju metodološkog okvira za standardizaciju modela interoperabilnih 
platnih sistema zasnovanih na ontologijama i primeni predloženog 
metodološkog okvira za razvoj ostalih sistema elektronskog poslovanja; 

• Definisanju okvira za determinisanje domenske ontologije interoperabilnih 
sistema elektronskog poslovanja; 

• Razvoju originalnog modela interoperabilnog elektronskog poslovanja platnog 
sistema zasnovanog na ontologijama i dobijenog standardizacijom organizacije 
podataka i poslovnih procesa; 

• Razvoju originalnog modela za akviziciju i distribuciju, pretprocesiranje, 
procesiranje i postprocesiranje poruka interoperabilnog elektronskog poslovanja 
platnih sistema zasnovanih na ontologijama i poslovnih procesa interoperabilnog 
elektronskog poslovanja uopšte; 

• Razvoju uopštenog modela poruke i modela poslovnog pravila sadržanog u 
poruci; 

• Razvoju matematičkog modela elektronskog poslovanja platnih sistema; 

• Razvoju domenske ontologije platnih sistema zasnovane na ISO15944-4:2007 
međunarodnom standardu; 

• Primeni Resource-Event-Agent ontologija u inetroperabilnom elektronskom 
poslovanju platnih sistema; 
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• Dcfinisanju okvira za primenu Resource-Event-Agent ontologija u 
interoperabilnom elektronskom poslovanju; 

• Razvoju, sistematizaciji i detaljnoj analizi implementacije procesa 

interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na 
ontologijama; 

• Razvoju modela Registracionog tela za sledljivost poslovnih procesa i validaciju 
podataka povezanih sa poslovnim procesom. 

Rad na ovoj disertaciji rezultovao je i nizom stručnih doprinosa, od kojih su najvažniji: 

• Analiza i identiiikacija najvažnijih problema koji otežavaju elektronsko 
poslovanje platnih sistema u Republici Srbiji; 

• Metoda za implementaciju predloženog modela interoperabilnog elektronskog 
poslovanja platnih sistema u Srbiji; 

• Metoda projektovanja i realizacije interoperabilnih sistema elektronskog 
poslovanja u Srbiji; 

• Standardizovani projektni zadatak sistema elektronskog poslovanja platnih 
sistema; 

• Standardizovani pristup realizaciji projektnog zadatka implementacije sistema 
elektronskog poslovanja platnih sistema; 

• Rešenje za kliring finansijskih transakcija nezavisno od instrumenata plaćanja; 

• Rešenje za poravnanje finansijskih transakcija nezavisno od instrumenata 
plaćanja; 

• Razvoj modela kliringa nezavisnog od instrumenta plaćanja; 

• Rešenje interoperabilnog elektronskog poslovanja platnog sistema sa 
mogućnošću primene i u drugim oblastima elektronskog poslovanja; 

• Rešenje tela za registraciju poruka i verifikaciju poslate poruke i potvrde 
prijema; 

• Rešenje za standardizaciju poslovnih poruka u segmentima poslovanja za koje 
nije izvršena standardizacija; 

• Rešenje za standardizaciju akvizicije i distribucije podataka u sistemima 
elektronskog poslovanja; 

• Prezentovanje primene rezultata u drugim segmentima elektronskog poslovanja 
koji mogu da se standardizuju primenom adresibilnih poruka sa poslovnom 
logikom, među kojima su i meteorološki sistemi; 

• Analiza zarada nastalih primenom elektronskog poslovanja; 

• Rezultati istraživanja koja daju eksplicitan doprinos standardizaciji 
implementacije sistema elektronskog poslovanja; 

• Adaptibilni, fleksibilni, proširivi, skalabilni model koji omogućava integritet 
poslovnih procesa i podataka. 

Rezultati istraživanja realizovanih u okviru ove doktorske disertacije objavljeni su u 

više radova u časopisima i saopšteni na naučnim skupovima i to: 

Radovi objavljeni u časopisu međunarodnog značaja na SCI listi: 

1. S. Babić, Z. Anđelković, D. Barać, Z. Bogdanović, M. Despotović-Zrakić, Model of 

Interoperable e-Business of Payment Systems Based on Ontologies, - Metalurgia 

International, no. 2-2013, pp. 150-155, 2013 (IF=0.084) (ISSN: 1582-2214). 
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2. J. Lukić, S. Babić, A. Labus, A. Milić, B. Radenković, Building Business 
Intelligence System for B2B e-Business Using KPI, - Metalurgia International, рад 
прихваћен за објављивање, (IF=0.084) (ISSN 1582-2214). 

3. S. Babić, Z. Andjelković, N. Lekić, The Clearinghouse - A Pattem for Supply Chain 
Information Exchange, - Actual Problems of Economics, рад прихваћен за 
објављивање, (IF=0.039) (ISSN 1993-6788). 

Rad u vodećem časopisu nacionalnog značaja: 

1. S. Babić, Z. Anđelković, Distribuirane baze podataka, -Info Science, JISA info : 
časopis za informatiku, računarstvo i telekomunikacije Jugoslovenskog 
informatičkog saveza, 1/1995, pp. 28-31, 1995, (ISSN: 0354-5334). 

Radovi saopšteni na skupu međunarodnog značaja štampani u celini: 

1. S. Babić, Z. Anđelković, V. Manić, Z. Stević, Evropski standardi platnih poruka kao 
osnov razvoja sistema kliringa naloga, -Naučno-stručni Simpozijum INFOTEH®- 
JAHORINA, Jahorina, Republika Srpska, 26.-28. mart 2008. 

2. S. Babić, Struktura i tipovi adresibilnih standardizovanih pomka koje u sebi sadrže 
poslovnu logiku, -17. telekomunikacioni forum TELFOR 2009, Beograd, Republika 
Srbija, 24.-26. novembar 2009. 

3. S. Babić, B. Milosavljević, Z. Anđelković, Implementacija sistema lanaca 
snabdevanja, -Naučno-stručni Simpozijum INFOTEH®-JAHORINA, Jahorina, 
Republika Srpska, 17.-19. mart 2010. 


Radovi saopšteni na skupu nacionalnog značaja štampani u celini: 

1. S. Babić, Z. Anđelković, Upravljanje implementacijom IT sistema za podršku 
poslovnim procesima, - VII Majska konferencija o strategijskom menadžmentu sa 
međunarodnim učešćem, Zaječar, Republika Srbija, 26.-28. maj 2011. pp. 931-944. 

2. S. Babić, B. Milosavljević, Z. Anđelković, Korišćenje uzorka document message u 
integraciji poslovnih sistema, -YU Info XVI konferencija iz oblasti informacionih i 
komunikacionih tehnologija, Kopaonik, Republika Srbija, 03.-06. mart 2010. 

3. R. Petković, S. Babić, SAGA SEP transportni sistem u finansijskoj industriji, - 
Bankinfo XIII savetovanje informatičara u bankama, Palić, Republika Srbija, 08.- 
10. novembar 2006. 

4. S. Babić, I. Bojičić, I. Tamburić, Realizacija platnih sistema korišćenjem 
standardnih aplikativnih komponenti, -XIII Infofest Festival informatičkih 
dostignuća, Budva, Crna Gora, 24.-30. septembar 2006. 

5. R. Pavićević, B. Tončić, S. Babić, Metodološki aspekti razvoja infonnacionog 
sistema Narodne banke Jugoslavije, -XVII naučno stručni skup InfoTech, Vmjačka 
banja, Republika Srbija, 20.-23. juni 2000. 

6. R. Pavićević, S. Babić, Informacioni sistemi u bankarstvu i centralni bankarski 
sistem, -Infofest Festival informatičkih dostignuća, Budva, Cma Gora, 26. 
septembar - 02. oktobar 1999. 

7. M. Matić, M. Remović, S. Babić, MDB Editor Teodora, -YU Info XVI konferencija 
iz oblasti informacionih i komunikacionih tehnologija, Kopaonik, Republika Srbija, 
24.-26. mart 1998. 
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8. M. Matić, M. Remović, S. Babić, Upis i nastava u srednjem obrazovanju - 
Programski paket UNA u IS-u tehničke škole Beograd - Železnik, -XII naučno- 
stručni skup Infotech, Vrnjačka banja, Republika Srbija, 16.-20. juni 1997. 

9. A. Ninković, S. Babić, Računarske mreže i BBS sistemi, vrste i mogućnosti 
upotrebe, -44. Sabor psihologa Srbije, Institut za kriminološka i sociološka 
istraživanja, primena računara i mreže u psihologiji, Vmjačka Banja, Republika 
Srbija 15.-19- maj 1996. 

10. Z. Anđelković, S. Babić, Bezbednost i zaštita podataka u zdravstvu - multimedijalno 
izlaganje rada, -Medistat, Aranđelovac, Republika Srbija, juni 1996. 

11. S. Babić, Početna iskustva u primeni AS/400 u poslovnim procesima u Lola 
Korporaciji a.d., -SINFON Studentski radovi u informatici i računarskim naukama, 
Zlatibor, Republika Srbija, 29. oktobar- 02. novembar 1994. 
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8 Buduća istraživanja 


Istraživanje započeto u okviru ove teze rezultovalo je modelom interoperabilnog 
elektronskog poslovanja platnih sistema zasnovanih na ontologijama. Model pokazuje 
da je moguća primena i u drugim segmentima elektronskog poslovanja kako bi se 
obezbedila interoperabilnost elektronskog poslovanja. Skup budućih istraživanja 
proisteklih iz rezultata ovog rada jeste: 

• razvoj okvira za standardizaciju arhitekture poslovnih procesa različitih 
domena u okviru poslovnog sistema (na primer preduzeća ili države) 
zasnovanog na razmeni adresibilnih poruka koje sadrže poslovnu logiku; 

• izolacija objekata i procesa različitih domena jednog poslovnog sistema, 
tipizacija njihovih odnosa, strukturiranje poslovne logike poruke u odnosu na 
tipove objekata i procesa različitih domena i mogućnost standardizacije na 
nivou poslovnog sistema; 

• fenomenološka analogija disparatnih sistema zasnovanih na adresibilnim 
porukama koje sadrže poslovnu logiku; 

• definisanje arhivističkih kategorija i primena metoda arhivistike u cilju 
standardizacije i optimizacije poslovnih procesa arhiviranja poslovne 
dokumentacije poslovnih procesa, odnosno adresibilnih poruka koje sadrže 
poslovnu logiku; 

• strukturiranje poslovnih sistema u odnosu na standardizovanu dokumentaciju 
poslovnih procesa, odnosno adresibilnih poruka koje sadrže poslovnu logiku i 
sa tog stanovišta izrade domenske ontologije koja bi dokazala neopravdanost 
postojanja domenskih registracionih tela i dokazala jedinstvenost centralnog 
registracionog tela poslovnog sistema nad svim domenima u sistemu. 

Istraživanje na postizanju interoperabilnog modela elektronskog poslovanja platnih 
sistema pokazalo je da uvođenje globalnih standarda u razmeni poslovnih informacija sa 
domaćim i stranim poslovnim subjektima omogućava širenje palete inoviranih 
proizvoda elektronskog poslovanja koji mogu da se ponude tržištu, kao što je korišćenje 
automata u poslovnim procesima izdavanja polisa obaveznog osiguranja. 

Semantička interoperabilnost poslovnih sistema koja se postiže na nivou podataka, 
servisa i poslovnih procesa uz razvijenu domensku ontologiju elektronskog poslovanja 
platnih sistema daje osnovu da buduća istraživanja u oblasti automatizacije prevođenja 
ontologija u šeme podataka mogu dati rezultate koji bi u oblasti razvoja zajedničkih 
infonnacionih modela elektronskog poslovanja doprineli standardizaciji razvoja 
infonnacionih sistema elektronskog poslovanja. 
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9 Zaključak 

Model interoperabilnog elektronskog poslovanja platnog sistema zasnovan na 
standardizovanom ontološkom modelu podataka i procesa, predložen u tezi, omogućava 
unapređenje procesa elektronskog poslovanja platnih sistema. Unapređenja modela 
ogledaju se u: implementaciji standarda finansijske industrije i ostalih segmenata 
elektronskog poslovanja, oblasti primene savremenih modela platnih sistema i u drugim 
oblastima, u procesima transporta poruka elektronskog poslovanja, u procesiranju 
poruka elektronskog poslovanja, domenu primene uniformisanja modela sa 
distribuiranim funkcionalnostima, implementaciji savremenih tehnologija. 

Predloženi model prati brz razvoj savremenih informacionih tehnologija i diktira 
komponentni razvoj, obezbeđuje mogućnost da se izvrši brza implementacija 
komponenata u postojeće informacione sisteme. Definisanjem modela za integraciju 
razvijenih i buduće razvijenih softverskih komponenata omogućena je brza 
implementacija i primena novih tehnologija. 

Pored razmatranja o platnim sistemima, informacija o razvoju i eksploataciji platnih 
sistema, predmet proučavanja teze je predviđanje načina funkcionisanja platnih sistema 
u budućnosti, metodologija zadavanja rešavanja problema, čime je rad obuhvatio razvoj 
generičkog modela platnog sistema za transport, prijema platnih poruka, 
pretprocesiranje i procesiranja finansijskih instrukcija i transakcija sadržanih u njima. 

Obuhvaćeno je i generisanje aplikativnih komponenata i komponenata baze podataka iz 
definicija koje nude savremeni standardi, korišćenjem dostupnih alata nad objavljenim i 
javno dostupnim elementima finansijskih standarda i pokazano da se komponente 
dobijene na taj način mogu koristiti u produkciji. Time je obezbeđeno tehničko i 
tehnološko unapređenje podrške poslovnim procesima koje podržavaju sistemi za 
elektronsko poslovanje platnih sistema kao i njihova brza implementacija. Prikazano je 
da se platni sistemi različitih nivoa se sastoje od standardnih ekvivalentnih elemenata u 
rekurzivnoj strukturi. 

U okviru disertacije prikazana je informatička organizacija procesorske kuće sa 
poslovima registracionog tela, koje je u ovom radu definisano, koja bi se bavila 
elektronskom razmenom podataka i procesiranjem poslovnih zahteva. Takav servisni 
centar, baziran na rezultatima ovoga rada, mogao bi, osim platnih poruka, da procesira i 
poruke drugih realnih sistema koji su bazirani na adresibilnim porukama koje u sebi 
sadrže informacije potrebne za procesiranje. 

Na bazi predloženog modela integracije elektronskog poslovanja platnih sistema 
zasnovanog na ontologijama projektovano je originalno rešenje integracije platnih 
sistema. Realizacija se sastojala iz utvrđivanja domenske ontologije platnih sistema, i 
primene metodologije zadavanja sistema detaljno opisanim dokumentima potrebnim za 
definisanje sistema, kreiranje baze podataka, dinamičkih biblioteka i komponenata 
sistema, definisanja načina distribucije komponenata i poslovnih pravila sistema. 
Razvoj i testiranje primera rešenja integracije pokazali su da se interoperabilnost 
elektronskog poslovanja platnih sistema može uspešno ostvariti predloženom 
integracijom. Na osnovu rezultata tokom eksperimentalne analize predloženog rešenja i 
primene u produkciji, izvršena je verifikacija i primena predloženog modela. Predloženo 
rešenje je našlo primenu u praksi koja se ogleda u uspešnosti klirinških sistema 
Udruženja banaka Srbije za kliring čekova i direktno zaduženje. 
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Predloženim modelom utvrđeno je postizanje interoperabilnosti na sintaksnom i 
semantičkom nivou. Eksperiment je pokazao da predloženo rešenje nudi visok stepen 
efektivnosti i efikasnosti, a zasnovanost na standardizovanim komponentama i 
zadovoljavajući stepen ekonomičnosti. 
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13 Prilozi 

Prilog 1: 

OPERATIVNA PRAVILA 
ZA REALIZACIJU KLIRINGAI OBRAČUNA 
PO OSNOVU DIREKTNIH ZADUŽENJA 

1. Osnovne odredbe 

1.1. U skladu sa stavom 1. tačke 1. Odluke o obavljanju platnog prometa po osnovu direktnih zaduženja 
(Službeni glasnik RS, br. 31/2007, u daljem tekstu: Odluka), direktnim zaduženjem se smatraju 
transakcije koje inicira Poverilac na osnovu dospelih hartija od vrednosti, menica ili ovlašćenja koje 
Dužnik daje svojoj banci i svom Poveriocu u skladu sa članom 4. stav 4. Zakona o platnom prometu (u 
daljem tekstu: Direktna zaduženja). 

1.2. Osnovi iz tačke 1.1. ovih Operativnih pravila predstavljaju ovlašćenja izdata od strane Dužnika (u 
daljem tekstu: Mandat) na osnovu kojih Poverilac može da inicira transakcije za naplatu prema uslovima 
navedenim u njima, u skladu sa nacionalnom šemom direktnog zaduženja definisanom od strane Narodne 
banke Srbije. 

1.3. Direktna zaduženja se realizuju u međubankarskom obračunu koji u skladu sa stavom 1. tačke 3. 
Odluke može obavljati pravno lice koje je osposobljeno za poslove kliringa i sa kojim učesnici zaključe 
ugovor o kliringu čiji su sastavni deo Operativna pravila (u daljem tekstu: Procesor). 

1.4. Učesnici kliringa iz tačke 1.3. ovih Operativnih pravila (u daljem tekstu: Učesnici) mogu biti: 

a) Banke iz člana 2. Tačka 10. Odredba pod a) Zakona o platnom prometu, koje poseduju 
dozvolu za rad Narodne banke Srbije 

b) Ministarstvo finansija - Uprava za trezor 

1.5. U skladu sa tačkom 1. Odluke, kliringom se smatra izračunavanje multilateralnih neto pozicija za 
učesnike u kliringu, nastalih po osnovu podnetih instrukcija Direktnog zaduženja (u daljem tekstu: 
Kliring). 

1.6. U skladu sa tačkom 2. Odluke, u Kliringu se mogu izvršavati nalozi Direktnog zaduženja čiji su 
pojedinačni iznosi do 1.000.000,00 dinara 

1.7. U skladu sa tačkom 5. Odluke, obračun direktnih zaduženja se vrši kao neto obračun izračunatih 
multilateralnih neto pozicija preko računa koji se vode kod Narodne banke Srbije (u daljem tekstu: 
Obračun) i to: 

a) za Banke, preko žiro računa banaka u RTGS sistemu; 

b) za Ministarstvo finansija - Uprava za trezor, preko konsolidovanog računa trezora Republike 
Srbije u RTGS sistemu; 

c) za Procesora, preko obračunskog računa otvorenog u skladu sa Zakonom o platnom prometu i 
stavom 2. tačke 5. Odluke. 

1.8. Kliring i Obračun se izvršavaju ciklično (u daljem tekstu: ciklus Kliringa), u terminima definisanim 
Operativnim pravilima Procesora. 

1.9. U skladu sa tačkom 6. Odluke, Kliring i Obračun direktnih zaduženja se vrši prema odredbama 
Odluke i u skladu sa Operativnim pravilima za RTGS sistem koja utvrđuje Narodna banka Srbije i 
Operativnim pravilima Procesora. 

1.10. U skladu sa tačkom 7. Odluke, Udruženje banaka Srbije u svojstvu Procesora, ovim Operativnim 
pravilima utvrđuje: 

A. Način i uslove za priključenje u Kliring 

B. Mere zaštite i odgovornosti učesnika u Kliringu 

C. Podatke i poruke u sistemu Kliringa 

D. Način realizacije ciklusa Kliringa i obezbeđenja Obračuna 

E. Način realizacije Obračuna 

F. Sistem obaveštavanja 

G. Način rešavanja reklamacija 

H. Terminski plan Kliringa 

I. Uslove za isključenje iz Kliringa 

J. Naknade za poslove Kliringa 

2.0 Uslovi i način priključenja 

2.1. Uslovi za priključenje Učesnika u Kliring su: 

a) da bude učesnik RTGS sistema; 

b) da prijavi bankarski kod za identifikaciju (BIC kod) koji koriste u RTGS sistemu; 
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c) da ispunjava tehničke uslove i standarde za povezivanje, utvrđene uputstvom Narodne banke 
Srbije za primenu odluke kojom se uređuje elektronski način obavljanja platnog prometa; 

d) daje povezan na mrežu Procesora; 

e) da prijavi lica ovlašćena za kontakt sa Procesorom po poslovima Kliringom; 

f) da zaključi ugovor sa Procesorom kojim prihvata Operativna pravila; 

g) da Procesoru i Narodnoj banci Srbije dostavi ovlašćenje na osnovu koga Procesor može po 
osnovu Obračuna da vrši zaduženja njegovog računa u RTGS sistemu. 

2.2. Odluku o priključenju Učesnika u Kliring donosi Procesor na osnovu podnetog zahteva za 
priključenje overenog pečatom i potpisanog od strane lica ovlašćenog za zastupanje i ispunjenja uslova iz 
tačke 2.1. ovih Operativnih pravila. 

3. Mere zaštite i odgovornosti 

3.1. Mere zaštite koje su Učesnici su dužni obezbede pri realizaciji Direktnih zaduženja se odnose na: 

a) Fizičku kontrolu pristupa računarskim resursima koji služe za priključenje na mrežu 
Procesora; 

b) Zaštićenu administraciju hardverskih i softverskih sistema namenjenih realizaciji Direktnih 
zaduženja; 

c) Kontrolu operacija, obrade i pristupa podacima vezanim za realizaciji Direktnih zaduženja, 
prema standardima defmisanim aktima Učesnika za sprovođenje mera unutrašnje kontrole; 

d) Primenu drugih mera u skladu sa dobrim poslovnim običajima i praksom. 

3.2. Učesnici su dužni da Procesoru prijave najmanje po jednog zaposlenog za poslove: 

a) Administratora sistema, zaduženog za primenu mera zaštiti koje obuhvataju: 

- Administraciju komunikacionih resursa koji služe za bezbedno priključenje i rad u mreži 
Procesora; 

- Realizaciju platnog prometa u skladu sa uputstvom o elektronskom obavljanju platnog prometa 
koje donosi Narodna banka Srbije; 

- Sproveđenje odluke Procesora o privremenom isključenju Učesnika iz Kliringa, odnosno o 
njihovom uključenju u Kliring 

b) Ovlašćeno lice, zaduženo za defmisanje i realizaciju procedura i operacija vezanih za Direktna 
zaduženja koje obuhvataju: 

- Definisanje procedura za sprovođenje transakcija Direktnog zaduženja u skladu sa zakonskim 
propisima i ovim Operativnim pravilima, i njihovu realizaciju 

- Kontrolu operacija vezanih za Direktna zaduženja, u skladu sa defmisanim procedurama; 

- Podnošenje informacija o maksimalnom iznosu do koga Učesnik učestvuje u Kliringu; 

- Podnošenje i rešavanje reklamacija po transakcijama Direktnih zaduženja. 

3.3. Učesnici su odgovorni za verodostojnost, kodiranje i sadržaj poslatih poruka, njihovo slanje u skladu 
sa terminskim planom Kliringa, kao i za svaki propust svojih Administratora sistema i Ovlašćenih lica. 

3.4. Svaki propust u primeni mera zaštite iz tačke 3. ovih Operativnih pravila od strane Učesnika može 
biti osnov za nadoknadu nastale štete ostalim Učesnicima Kliringa. Nesporan fmansijski gubitak 
Učesnika u kliringu, pod kojim se u smislu ovih Oprativnih pravila podrazumeva iznos realizovanih 
transakcija Direktnog zaduženja, uzrokovan propustima u primeni mera zaštite drugih Učesnika, 
nadoknađuje Učesnik koji je svojim propustima u primeni mera zaštite uzrokovao nastanak finansijskog 
gubitka, a realizuje Procesor u ciklusu Kliringa transakcijama za povraćaj sredstava (Return). 

4. Podaci i poruke u sistemu Kliringa 

4.1. Uputstvom o nameni i formatu poruka za sistem Kliringa i Obračuna po Direktnim zaduženjima koje 
je dato u Prilogu 1. ovih Operativnih pravila (u daljem tekstu: Uputstvo), na osnovama tehnologije i 
pravila u SEPA (Single Euro Payments Area) okruženju je definisan set instrukcija i poruka za realizaciju 
Direktnih zaduženja, razmenu informacija o ciklusu Kliringa i Obračuna, njihov sadržaj, format i namena. 
Razmena poruka sa instrukcijama Direktnog zaduženja i informacijama o Kliringu i Obračunu se vrši 
putem mreže Procesora. 

4.2. Razmena poruka za realizaciju Obračuna se vrši putem mreže Narodne banke Srbije, na način i u 
formatu defmisanim od strane RTGS sistema, sa nezavisnim ulazno/izlaznim kanalima i elementima 
zaštite. 

5. Način realizacije ciklusa Kliringa i obezbeđenja Obračuna 

5.1. Neto pozicija u ciklusu Kliringa predstavlja razliku u fmansijskom iznosu između sume iznosa 
podnetih (prilivi) i sume iznosa primljenih (odlivi) instrukcija Direktnog zaduženja (u daljem tekstu: Neto 
pozicija), koja se obračunava na nivou svakog Učesnika i može biti pozitivna (više priliva nego odliva), 
negativna (više odliva nego priliva) i nulta. 
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5.2. Za obezbeđenje Obračuna, koristi se informacija o maksimalnom iznosu zaduženja Učesnika u 
kliringu (u daljem tekstu: Limit zaduženja), a koju svaki Učesnik dostavlja Procesoru pre početka 
ciklusa Kliringa. 

Učesnik može menjati Limit zaduženja u bilo kom trenutku, pri čemu je važeći poslednji dostavljeni 
Limit zaduženja. 

5.3. Obaveza svakog Učesnika je da obezbedi na računu u RTGS sistemu dovoljno sredstava za 
realizaciju negativne Neto pozicije, odnosno da dostavljanjem Limita zaduženja u skladu sa stanjem na 
računu u RTGS sistemu, obezbedi da njegova negativna Neto pozicija bude realizovana u Obračunu. 

5.4. Za svakog Učesnika kod koga je negativna Neto pozicija veća od Limita zaduženja, Procesor vrši 
odbijanje instrukcija Direktnog zaduženja koje se odnose na zaduženje njegovog računa, prema iznosu 
zaduženja (od najmanjeg ka najvećem), a do nivoa negativne Neto pozicije jednake ili manje od Limita 
zaduženja, uz ponavljanje ciklusa Kliringa bez odbijenih instrukcija Direktnog zaduženja. 

5.5. Procesor vrši verifikaciju ciklusa Kliringa, proverom usklađenosti negativne Neto pozicije svakog 
Učesnika sa stanjem na njegovom računu u RTGS sistemu. 

Učesnici koji nemaju dovoljno sredstava na računu u RTGS sistemu za realizaciju negativne Neto 
pozicije se isključuju iz ciklusa Kliringa, uz odbijanje instrukcija Direktnih zaduženja koja se odnose na 
tog Učesnika i ponavljanje ciklusa Kliringa. 

5.6. Ciklus Kliringa Procesor realizuje jednom dnevno, nakon zatvaranja RTGS sistema za prijem naloga 
za plaćanje, po pravilu sa instrukcijama Direktnog zaduženja čije je dospeće narednog dana, a Obračun po 
ovom ciklusu Kliringa Procesor realizuje na dan dospeća, odmah po otvaranju RTGS sistema za prijem 
naloga za plaćanje. 

6. Način realizacije Obračuna 

6.1. Procesor vrši realizaciju Obračuna za verifikovani ciklus Kliringa preko svog obračunskog računa u 
RTGS sistemu, ispostavljanjem naloga za zaduženje računa Učesnika sa negativnom Neto pozicijom u 
ciklusu Kliringa (u korist obračunskog računa Procesora) i naloga za odobrenje računa Učesnika sa 
pozitivnom Neto pozicijom u ciklusu Kliringa (na teret obračunskog računa Procesora). 

6.2. Procesor prvo ispostavlja sve naloge za izvršenje negativnih Neto pozicija (zaduženje računa 
Učesnika u RTGS sistemu), a nakon njihove realizacije, Procesor ispostavlja sve naloge za izvršenje 
pozitivne Neto pozicije (odobrenje računa Učesnika u RTGS sistemu). 

7. Sistem obaveštavanja 

7.1. Obaveza Procesora je obaveštavanje Učesnika najmanje o: 

a) Promenama statusa Učesnika (Isključenje/uključenje) 

b) Validnosti primljenih poruka 

c) Odbijanju instrukcija Direktnog zaduženja 

d) Neto poziciji u ciklusu Kliringa 

e) Ostvarenom prometu u ciklusu Kliringa 

f) Realizovanim instrukcijama Direktnim zaduženjima 

Set poruka za obaveštavanje Učesnika, njihov sadržaj, format i namena, definisan je Uputstvom koje je 
dato u Prilogu 1. ovih Operativnih pravila. 

7.2. Obaveza Učesnika je obaveštavanje Procesora najmanje o: 

a) Promeni statusa Učesnika u sistemu Kliringa (Isključenje/uključenje) 

b) Limitima zaduženja 

c) Odbijanju instrukcija Direktnog zaduženja 

Set poruka za obaveštavanje Procesora, njihov sadržaj, format i namena, definisan je Uputstvom koje je 
dato u Prilogu 1. ovih Operativnih pravila. 

7.3. Banke dužnika je obavezna da na osnovu dobijene instrukcije direktnog zaduženja koja u 
elektronskom obliku sadrži nalog za naplatu i ovlašćenje koje je dužnik ispostavio poveriocu, inicira 
postupak prinudne naplate u slučaju nemogućnosti realizacije zaduženja zbog nedostatka raspoloživih 
sredstava na računu dužnika i/ili blokade računa dužnika, a prema tački 6. Odluke o sprovođenju prinudne 
naplate sa računa klijenta. 

Set poruka za iniciranje prinudne naplate, njihov sadržaj, format i namena, defmiše svojim odlukama i 
uputstvima Narodna banka Srbije. 

7.4. Narodna banka Srbije i Procesor razmenjuju informacije od značaja za realizaciju Obračuna i 
stabilnost platnog sistema u koje spadaju o: 

a) Promene statusa Učesnika u sistemu Kliringa (Isključenje/uključenje) 

b) Promene statusa Učesnika u RTGS sistemu (blokade/deblokade) 

c) Informacije o usklađenosti negativne Neto pozicije Učesnika u ciklusu Kliringa sa stanjem na 
računu u RTGS sistemu 
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d) Informacije o nerealizovanju instrukcija Direktnih zaduženja zbog nedostatka sredstava na 
računu Učesnika u RTGS sistemu 

e) Drugi događaji od značaja za stabilnost platnog sistema 

Način razmene informacija između Narodne banke Srbije i Procesora defmiše Narodna banka Srbije. 

8. Način rešavanja reklamacija 

8.1. Reklamacije po realizovanim ili nerealizovanim instrukcijama Direktnog zaduženja u ciklusu 
Kliringa i Obračuna, a koje se odnose na propuste nastale u ciklusu Kliringa ili Obračuna, podnose se 
Procesoru u roku od 10 dana od dana završetka ciklusa Kliringa i Obračuna. 

Odluku i rešenje po ovim reklamacijama donosi posebna komisija koju formira Procesor, a u kojoj pored 
članova iz redova Procesora mogu participirati i članovi iz redova Učesnika. Komisija za rešavanje 
reklamacija može postojati kao stalno telo pri Procesoru, koje pri konstituisanju donosi Pravilnik o radu 
kojim se defmiše sastav, dužina mandata članova, način rada i donošenja odluka (u daljem tekstu: 

Komisija). 

Komisija donosi Odluku i rešenja po reklamaciji u roku od 10 dana od dana podnošenja reklamacije. 
Odluka Komisije predstavlja osnov za izvršenje instrukcija Direktnog zadužena kojima se vrši povraćaj 
sredstava (Return), u skladu sa Uputstvom datim u Prilogu 1. ovih Operativnih pravila. 

8.2. Sporove i reklamacije po realizovanim ili nerealizovanim instrukcijama Direktnog zaduženja u 
ciklusu Kliringa i Obračuna, a koje se odnose na propuste učinjene od strane Učesnika, rešavaju 
međusobno Učesnici. Za ekpertizu i rešavanje ovih sporova i reklamacija, Učesnici mogu takođe koristiti 
usluge Komisije, pri čemu se angažovanjem Komisije obavezuju za prihvatanje njene Odluke po 
nastalom sporu. 

Sporazum Učesnika ili Odluka Komisije predstavlja osnov za izvršenje instrukcija Direktnog zadužena 
kojima se vrši povraćaj sredstava (Return), u skladu sa Uputstvom datim u Prilogu 1. ovih Operativnih 
pravila ili plaćanja od strana banke poverioca. 

8.3. Reklamacije po realizovanim ili nerealizovanim instrukcijama Direktnog zaduženja u ciklusu 
Kliringa i Obračuna, a koje se odnose na sporne i različito tumačene osnove naplate (mandate) od strane 
Dužnika i Poverioca, rešavaju međusobno Dužnik i Poverilac. 

Sporazum Dužnika i Poverioca predstavlja osnov za izvršenje instrukcija Direktnog zaduženja kojim se 
vrši povraćaj sredstava od strane Poverioca (Reversal) u skladu sa Uputstvom datim u Prilogu 1. ovih 
Operativnih pravila. 

9. Terminski plan Kliringa 

9.1. Kliring i Obračun se obavlja svakog radnog dana kojima se u smislu ovih Operativnih pravila ne 
smatraju subota, nedelja i dani državnih i verskih praznika koji su proglašeni neradnim danima. 

9.2. Kliring i Obračun se ne mogu obavljati danima u kojima ne radi RTGS sistem, bez obzira na razloge 
zbog kojih RTGS sistem ne radi. 

9.3. Dnevni terminski plan Kliringa i Obračuna mora uvek biti usklađen sa dnevnim terminskim planom 
RTGS sistema koji donosi Narodna banka Srbije. 

9.4. Radno vreme, kao i dnevni terminski plan Kliringa i Obračuna su definisani Terminskim planom za 
sistem Kliringa i Obračuna po Direktnim zaduženjima koji je dat u Prilogu 2. ovih Operativnih pravila (u 
daljem tekstu: Terminski pian) 

9.5. Procesor može, po potrebi, povremeno i privremeno promeniti Terminski plan, o čemu je dužan da 
obavesti sve Učesnike i Narodnu banku Srbije 

9.6. Procesor može vršiti i trajne promene Terminskog plana, a obavezno pri promeni dnevnog 
terminskog planom RTGS sistema sa kojirn uvek mora biti usklađen. 

10. Uslovi iskijučenja Učesnika iz Kliringa 

10.1. Učesnik u Kliringu može biti privremeno ili trajno isključen iz Kliringa. 

10.2. Učesnik u Kliringu može biti privremeno isključen iz Kliringa: 

a) Ukoliko ne postupa u skladu sa Ugovorom o učešću u Kliringu i Obračunu koji je zaključio sa 
Procesorom 

b) Ukoliko ne primenjuje mere zaštiti predviđene tačkom 3. ovih Operativnih pravila 

c) Ukoliko nema dovoljno sredstava na računu u RTGS sistemu za realizaciju negativne Neto 
pozicije obracunate u ciklusa Kliringa 

d) Ukoliko u kratkom vremenskom intervalu (do 7 dana) višekratno (više od jednom) nema 
dovoljno sredstava na računu u RTGS sistemu za realizaciju negativne Neto pozicije obračunate 
u ciklusima Kliringa 

e) Ukoliko u kratkom vremenskom intervalu (do 7 dana) višekratno (više od jednom) 
postavljenim Limitom zaduženja implicira odbijanje instrukcija Direktnog zaduženja 
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f) Ukoliko neopravdano odbije izvršenje instrukcija Direktnog zaduženja po reklamaciji drugog 
Učesnika 

g) Ukoliko neprihvata zahtev Procesora ili drugog Učesnika upućenog preko Procesora za 
zajedničkom ekspertizom po reklamacijama ili ućešće u ekpertizi. 

h) Ukoliko neprihvata rezultate zajedničke ekspertize po reklamacijama, do konačnog rešenja 
spora. 

i) Ukoliko ne postupa u skladu sa drugim tačkama Operativnih pravila 

j) Ukoliko Procesor utvrdi sa Učesnik izaziva tehničke probleme u radu Kliringa 

10.3. Odluku o privremenom isključenju iz Kliringa i Obračuna donosi Procesor, koji o tome odmah 
obaveštava ostale Učesnike. 

Odluka Procesora o privremenom isključenju Učesnika iz Kliringa i Obračuna obavezno sadrži razloge 
isključenja, eventualne preduzete mere od strane Procesora i uslove za ponovno uključenje Učesnike sa 
rokom za njihovo ispunjenje. 

Ispunjenjem uslova navedenih u Odluci Procesora o privremenom isključenju Učesnika iz Kliringa i 
Obračuna u predviđenom roku, Učesnik se ponovo uključuje u Kliring i Obračun, o čemu Procesor 
odmah obaveštava ostale Učesnike 

Neispunjenje uslova za ponovno uključenje ili istekom roka, stiču se uslovi za trajno isključenje Učesnika 
iz Kliringa i Obračuna 

10.4. Učesnik u Kliring može biti trajno isključen iz Kliringa: 

a) Ukoliko se ustanovi da Učesnik ne ispunjava ili više ne ispunjava bilo koji od uslova za 
priključenje u Kliring navedenih u tački 2.1 ovih Operativnih pravila, 

b) U slučaju višestrukog, uzastopnog privremenog isključenje kojim se izazivaju smetnje u 
funkcionisanju sistema Kliringa i Obračuna, 

c) U slučaju neispunjenja uslova ili protekom roka navedenog u Odluci Procesora o 
privremenom isključenju Učesnika iz Kliringa i Obračuna 

d) Raskidom Ugovora o učešću u Kliringu i Obračunu potpisanog između Učesnika i Procesora 

10.5. Odluku o trajnom isključenju iz Kliringa i Obračuna donosi Procesor, koji o tome odmah 
obaveštava ostale Učesnike. 

Odluka Procesora o trajnom isključenju Učesnika iz Kliringa i Obračuna obavezno sadrži razloge 
isključenja, eventualne preduzete mere od strane Procesora. 

Po trajnom isključenju Učesnika iz Kliringa i Obračuna, Procesor će pokrenuti postupak za raskid 
Ugovora o učešću u Kliringu i Obračunu potpisanog između Učesnika i Procesora, ukoliko to Učesnik 
nije učinio. 

Ponovno uključenje Učesnika u Kliring je moguće sprovođenjem ponovo postupka za priključenje 
defmisanog u tački 2. ovih Operativnih pravila 

11. Naknada za poslove Kliringa 

11.1. Za pružanje usluga Kliringa i Obračuna po Direktnim zaduženjima, Procesor naplaćuje naknadu 
prema tarifi za izvršene usluge koju defmiše internim aktom (Odluka o tarifama usluga) i koja predstavlja 
sastavni deo Ugovora o učešću u Kliringu i Obračunu potpisanog između Učesnika i Procesora. 

12. Dodatni servisi Kliringa 

12.1. Procesor može u okviru dodatnih opcionih servisa (AOS - Additional Optional Service) ponuditi 
Učesnicima preuzimanje pojedinih prava i obaveza, vođenja evidencija i izveštavanja, u skladu sa 
unapred defmisanim pravilima prihvaćenim od strane Učesnika i Procesora. 

13. Završne odredbe 

13.1. Procesor može menjati ova Operativna pravila u cilju unapređenja poslova Direktnog zaduženja i 
usaglašavanja sa domaćim i međunarodnim standardima u tom domenu, uz saglasnost Narodne banke 
Srbije za izmene koje se odnose na usklađenost sa RTGS i ukupnim platnim sistemom. 

13.2. O svim izmenama ovih Operativnih pravila, Procesor je dužan da obavesti Učesnike najmanje 15 
(petnaest) dana pre stupanja na snagu tih izmena, osim za izmene kojima se ispravljaju uočene 
nepravilnosti u funkcionisanju sistema, koje stupaju na snagu odmah i moraju se sprovesti u najkraćem 
mogućem vremenu. 
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Prilog 2. 

UPUTSTVO O NAMENI I FORMATU PORUKA I TEHNOLOŠKA PRAVILA 
SISTEMA KLIRINGA I OBRAČUNA PO DIREKTNIM ZADUŽENJIMA 

1. UČESNICI 

Učesnici u Direktnim zaduženjima su: 

A) Dužnik (Debtor) je lice, fizičko ili pravno, koje izdaje Mandat (ovlašćenje) svome Poveriocu 
(Creditor) da ugovorenog dana ili u datom periodu izvrši naplatu definisanog/ih iznosa sa 
njegovog računa, u skladu sa uslovima navedenim u ovlašćenju. 

B) Poverilac (Creditor) je lice, fizičko ili pravno, koje inicira Direktno zaduženje računa 
Dužnika na osnovu i u skladu sa uslovima navedenim u primljenom Mandatu (ovlašćenju). 

C) Banka poverioca (Creditor Bank) je banka u kome je račun Poverioca i predstavlja Učesnika 
u sistemu kliringa. 

D) Banka dužnika (Debtor Bank) je banka u kome je račun Dužnika i predstavlja Učesnika u 
sistemu kliringa. 

E) Procesor je pravno lice koje je u svojstvu klirinške kuće (ACH - Automatic Clearing House) 
odgovorno za sprovođenje mehanizma obračuna multilateralne pozicije banaka Učenika u 
sistemu kliringa i njegove realizacije u RTGS sistemu Narodne banke (CSMs - Clearing and 
Settlement Mechanisms). 

2. PRAVA I OBAVEZE UČESNIKA 

2.1. Obaveza Dužnika je da dostavi Poveriocu personalizovan, verifikovan Mandat. 

2.2. Odgovornost za popunjenost obaveznog seta Mandata, jedinstvenost identifikacije Mandata i 
potpunost pravnog teksta nosi Poverilac. 

2.3. Poverilac je dužan da čuva (skladišti) Mandat u originalnom obliku i sa nepromenjenim sadržajem. 

2.4. Dužnik je obavezan da pre dospeća obaveze, podnese svojoj banci Mandat ili drugi vid ovlašenja 
(saglasnosti) za izvršenje zaduženje njegovog računa dogovorenog sa bankom, koji sadrži jednoznačnu 
identifikaciju Mandata i sve elemente za pravilno i nedvosmisleno identifikovanje uslova svake 
pojedinačne naplata. 

2.5. Poverilac i dužnik mogu da pre dospeća obaveze, podnesu svojim bankama Mandat sa zahtevom za 
njegovo evidentiranje u Registru mandata kod Procesora. 

2.6. Banka dužnika i/ili banka poverioca mogu Procesoru podneti zahtev za evidentiranje Mandata u 
Registar mandata, izmenu Mandata i povlačenje Mandata (banka dužnika samo u slučajevima 
predviđenim zakonskim propisima - stečaj ili likvidacija pravnog lica, smrt preduzetnika i dr.), prema 
uslovima i u rokovima koji su defmisani ovim Uputstvom. 

2.7. Procesor evidentira i čuva Mandat u Registru mandata u dematerijalizovanom obliku, sa istom 
važnošću kao i verifikovani Mandat u izvornom obliku. 

Banka dužnika i banka poverioca su odgovorni za potpunu usklađenost sadržaja Mandata u izvornom 
obliku i u dematerijalizovanom obliku podnetom Procesori za evidentiranje u Registru mandata. 
Evidentiranjem u Registru mandata, banka dužnika i banka poverioca, odnosno dužnik i poverilac 
prihvataju neporecivost njegovog izdavanja i evidentiranog sadržaja. 

2.8. Pri prodnošenju zahteva za evidentiranje Mandata u Registar mandata od strane banke poverioca, 
Procesor je dužan da obavesti banku dužnika o zahtevu za evidentiranje. 

Dužnik, odnosno banka dužnika može odbiti zahtev za evidentiranje Mandata. 

U slučaju eksplicitnog neprihvatanja, odnosno neodbijanja Mandata od strane banke dužnika u rokovima 
predviđenim ovim Uputstvom, Procesor će smatrati Mandat odbijenim. 

2.9. Pri podnošenju zahteva za evidentiranje Mandata u Registar mandata od strane banke dužnika, 
Procesor će Mandat odmah uključuje u evidenciju Registra mandata, a banku poverioca obavestiti o 
evidentiranom Mandatu. 

2.10. Dužnik i poverilac, odnosno banka dužnika i banka poverioca su dužni da svaku izmenu sadržaja i 
statusa Mandata evidentiranih u Registru mandata takođe evidentiraju u Registru mandata, pre 
ispostavljanja naloga za naplatu koji je u skladu sa izmenjenim Mandatom. 

2.11. Procesor je dužan da o zahtevu za izmenu sadržaja Mandata obavesti banku drugog učesnika, koja 
može odbiti izmenu Mandata. 

U slučaju eksplicitnog neprihvatanja, odnosno neodbijanja zahteva za izmenu Mandata u rokovima 
predviđenim ovim Uputstvom, Procesor će smatrati izmenu Mandata odbijenom. 

2.12. Zahtev za evidentiranje izmene sadržaja Mandata u Registru mandata, pored izmenjenih elemenata 
mora sadržati i sve druge, neizmenjene podatke i informacije iz originalnog Mandata. 

U Registru mandata važeći sadržaj Mandata je sadržaj evidentiran poslednjom izmenom Mandata. 
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2.13. Povlačenje Mandata se može odnositi samo na povlačenje osnovnog Mandat koje obuhvata i 
povlačenje svih aneksa tog Mandata. 

2.14. Pri podnošenju zahteva za povlačenje Mandata od strane banke dužnika, ukoliko je zahtev podnet u 
skladu sa zakonskim propisima kojima je predviđena mogućnost povlačenja, Procesor će odmah u 
evidenciji Registra mandata promeniti status mandata (Mandat povučen), a banku poverioca obavestiti o 
povlačenju Mandata. 

Odogovornost za ispunjenost zakonskih uslova za povlačenje Mandata, snosi banka dužnika. 

2.15. Pri podnošenju zahteva za povlačenje Mandata od strane banke poverioca, Procesor će odmah u 
evidenciji Registra mandata promeniti status mandata (Mandat povučen), a banku dužnika obavestiti o 
povlačenju Mandata. 

2.16. Procesor je dužan da o svim odbijenim zahtevima za evidentiranje i izmenu Mandata odmah 
obavesti podnosioca zahteva, na način predviđen ovim Uputstvom. 

2.17. Za Mandate u kojima se ista banka javlja i kao banka dužnika i kao banka poverioca, sa stanovišta 
ovih servisa, Procesor će smatrati primarnom njenu ulogu banke dužnika. 

2.18. Procesor je dužan da po instrukcijama zaduženja (Collection) ispostavljenim po Mandatima koji su 
evidentirani u Registru mandata izvrši dodatne kontrole u skladu ovim Uputstvom. 

2.19. Poverilac je dužan da Nalog za naplatu ispostavi u potpunosti prema uslovima navedenim u 
Mandatu i u rokovima predviđenim za Direktno zaduženje koji su defmisani Operativnim pravilima. 
Banka Poverioca može prihvatiti na realizaciju i Nalog za naplatu koji nije podnet u rokovima 
predviđenim za Direktno zaduženje defmisanim Operativnim pravilima, ali ne snosi odgovornost za 
odbijanje instrukcije zaduženja (Collection-a) od strane Dužnika, odnosno banke dužnika po osnovu 
kašnjenja. 

2.20. Banka Poverioca je odgovorna za proveru usklađenosti podataka iz Mandata i ispostavljenog 
Naloga za naplatu, kao i za generisanje i registrovanje instrukcije zaduženja (Collection) u skladu sa 
podnetim Mandatom i Nalogom za naplatu. 

2.21. Procesor je dužan da obavesti Banku Dužnika o svakoj ispostavljenoj instrukciji zaduženja 
(Collection). 

2.22. Ukoliko je Dužnik dostavio svojoj banci Mandat ili drugi vid ovlašćenja (saglasnosti) za izvršenje 
zaduženja njegovog računa, račun nije u blokadi i na računu Dužnika ima dovoljno sredstava za 
realizaciju instrukcije zaduženja (Collection), Banka Dužnika je dužna da izvrši ispostavljenu instrukciju, 
pri čemu može izvršiti rezervaciju ili zaduženje iznosa za naplatu iz instrukcije zaduženja (Collection) sa 
računa Dužnika, neposredno pre realizacije ciklusa Kliringa. 

2.23. Ukoliko Dužnik pre termina predviđenog za realizaciju ciklusa Kliringa nije dostavio banci Mandat 
ili drugi vid ovlašenja (saglasnosti) za izvršenje zaduženje njegovog računa, ili je račun Dužnika blokiran 
po bilo kom osnovu iniciranom od strane odgovarajuće organizacije za sprovođenje postupka prinudne 
naplate, ili na računu Dužnika nema ili nema dovoljno sredstava za realizaciju instrukcije zaduženja, 
Banka dužnika je dužna da odbije instrukciju zaduženja (Collection), obaveznim obveštavanjem 
Procesora o odbijanju, u skladu sa ovim Uputstvom. 

Banka Dužnika ne mora odbiti instrukciju zaduženja (Collection) zbog nedostatka sredstava na računu 
Dužnika ili bilo kojih drugih razloga koji su vezani za poslovni odnos banke sa Dužnikom (kreditiranje 
klijenta, generalno ovlašćenje sa naknadnom dostavom pojedinačnog i dr.), pri čemu taj poslovni odnos 
ne može dalje biti osnov za povraćaj sredstava po realizovanoj instrukciji zaduženja (Collection). 

U slučaju odbijanja instrukcija zaduženja (Collection) zbog nedostatka raspoloživih sredstava na računu 
dužnika i/ili blokade računa dužnika, Banka dužnika je dužna da inicira postupak prinudne naplate u 
skladu sa zakonskim propisima. 

2.24. U slučaju eksplicitnog neodbijanja ispostavljene instrukcije zaduženja (Collection) od strane Banke 
Dužnika u rokovima predviđenim Operativnim pravilima i ovim Uputstvom, Procesor će smatrati 
instrukciju zaduženja (Collection) prihvaćenom i uključiti je u ciklus Kliringa. 

2.25. Procesor je dužan da o svim odbijenim i nerealizovanim instrukcijama zaduženja (Collection), 
odmah obavesti banku poverioca i banku dužnika, na način predviđen ovim Uputstvom 

2.26. Procesor je dužan da po završetku Kliringa i Obračuna dostavi informaciju Učesnicima o svi 
realizovanim instrukcijama zaduženja (Collection), na način predviđen ovim Uputstvom 

2.27. Učesnici su dužni da za realizaciju instrukcija zaduženja (Collection) obezbede dovoljno sredstava 
na svojim računima u RTGS sistemu, kao i da usklađuju stanje računima u RTGS sistemu sa Limitom 
zaduženja evidentiranog kod Procesoru, a koje su Učesnici dostavili Procesoru u skladu sa Operativnim 
pravilima i ovim Uputstvom. 

2.28. Učesnici su dužni da u slučajevima reklamacija predviđenim Operatinom pravilima, prihvate rešenja 
Komisije za reklamacije kao osnov za izvršenje Direktnog zadužena kojim se vrši povraćaj sredstava 
(Return) ili plaćanja od strana banke poverioca (Reversal), u skladu sa ovim Uputstvom. Direktna 
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zaduženja po rešenjima Komisije za reklamacije, Procesor uključuje u ciklus Kliringa bez dodatnih 
ovlašćenja i verifikacije od strane Učesnika. 

2.29. Procesor može ponuditi, a Učesnici pojedinačni ili zajedno prihvatiti, preuzimanje pojedinih prava i 
obaveza definisanih Operativnim pravilima i ovim Uputstvom, prema unapred definisanim pravilima i 
uslovima dogovorenim između Učesnika i Procesora. 

3. STRUKTURA PODATAKA 

3.1. Struktura podataka Mandata 

3.1.1. Ugovorni odnos između Dužnika i Poverioca predstavlja pravni osnov za davanje Mandata kojim 
Dužnik ovlašćuje svoga Poverioca da ugovorenog dana ili u datom periodu, jednokratno (one-off) ili 
višekratno (recurrent) izvrši naplatu definisanog iznosa ili različitih iznosa sa njegovog računa prema 
mehanizmu za obračun obaveze dužnika i u skladu sa uslovima navedenim u Mandatu. 

3.1.2. Mandat potpisano i overeno od strane ovlašćenog lica Dužnika predstavlja personalizovani, 
verifikovani Mandat Poveriocu za podnošenje instrukcija Direktnog zaduženja (u daljem tekstu: Mandat). 

3.1.3. Osnovni elementi Mandata su definisani DS-01 strukturom SEPA pravila (papirni oblik), odnosno 
Mandata u dematerijalizovanom obliku DS-02 strukturom SEPA pravila (elektronski oblik): 



Element Mandata 

Mandatory/Optional 

1 . 

Jedinstveni identifikator Mandata. 

M 

2. 

1D Dužnika (matični broj) 

M 

3. 

Naziv Dužnika 

M 

4. 

Adresa Dužnika 

M 

5. 

Sedište Dužnika (poštanski broj i grad) 

М 

6. 

Kod države rezidencije Dužnika (za Srbiju: RS) 

М 

7. 

1D Poverioca (matični broj) 

М 

8. 

Naziv Poverioca 

М 

9. 

Adresa Poverioca 

М 

10. 

Sedište Poverioca (poštanski broj i grad) 

М 

11. 

Kod države rezidencije Poverioca (za Srbiju: RS) 

М 

12. 

Broj računa Dužnika 

М 

13. 

Naziv Banke Dužnika 

0 

14. 

BIC Banke Dužnika 

М 

15. 

Referenca Dužnika (poziv na broj Dužnika) 

0 

16. 

Broj osnovnog ugovora (na osnovu koga je izdat Mandat) 

0 

17. 

Pravni tekst 

м 

18. 

Oznaka tipa Mandata (jednokratan, višekratan) 

м 

19. 

Informacije za dodatne servise (AOS) 

0 

20. 

Datum potpisa (ispostavljanja) Mandata (verifikovanog) 

м 

21. 

Mesto potpisa Mandata 

м 

22. 

Potpis Mandata (matični podaci ovlašćenog lica Dužnika i potpis) 

м 


3.1.4. Elementi Mandata koji se odnose na dodatni servis evidentiranja mandata u Registru mandata 
(Informacije za dodatne servise) su: 


Datum dospeća prve 
obaveze 

M 

Dospeće prve obaveze. Ne može biti starije od datuma 
ispostavljanja mandata niti mlađe od datuma isteka mandata 

Datum isteka Mandata 

0 

Datum kada prestaju obaveze dužnika po mandatu. Ne može biti 
stariji od datuma ispostavljanja mandata niti od datuma dospeća 
prve obaveze. 

Broj obaveza po mandatu 

0 

Ukupan broj ugovorenih obaveza (maksimalan broj naloga za 
naplatu koje poverilac može podneti po mandatu) 

Metrika dospeća 

0 

Dan/Mesec/Godina 

Periodika dospeća u 
datoj metrici 

0 

Broj kojim se definiše periodika dospeća u datoj metrici 

Fiksni datumi dospeća 

0 

Fiksni datumi dospeća (osim prvog) 

Period tolerancije 

0 

Period tolerancije dospeća u zadatoj metrici iskazan u danima 
(može biti „+“, ili „+-„) 

Iznos plaćanja 

0 

Maksimalan iznos plaćanja koji se može javiti u nalogu 
zaduženja. 
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Za jednokratne mandate je jednak ukupnom iznosu. 

Za višekratne mandate sa jednakim iznosima obaveza, 
predstavlja iznos pojedinačne obaveze. 

Ukupan iznos plaćanja 
po mandatu 

0 

Ukupan iznos plaćanja po mandatu 

Valuta 

M 

Šifra valute iz ugovora 

Kursna lista 

0 

Kurna lista NBS, banke i dr. 

Vrsta kursa 

0 

Kupo vni/srednj i/prodaj ni 

Dodatni uslovi plaćanja 

0 

Dodatni, nestruktuirani uslovi naplate 

Povlačenje Mandata 

0 

Indikator povlačenja Mandata (od strane poverioca, odnosno 
dužnika u skladu sa zakonskim propisima) 

Uslovi povlačenja 

0 

Nestruktuirani uslovi opozivosti Mandata (od strane poverioca) 


3.1.5. Mandat može biti ispostavljen u papirnom ili elektronskom obliku. 

3.1.6. Elemente zaštite i elektronski potpis Mandata ispostavljenog u elektronskom obliku utvrđuju 
Dužnik i Poverilac, međusobno. 

3.1.7. Osnovna pravila u vezi sa formom i sadržinom Mandata ispostavljenog u papirnom obliku: 

Jedinstveni identifikator Mandata je obavezni element Mandata, opredeljuje ga Poverilac koji je 
dužan da obezbedi njegovu jedinstvenost (na nivou Poverioca); 

Nazivi polja u Mandatu (elemenata Mandata) moraju biti na najmanje jednom, a na najviše tri 
jezika koja se koriste u zemlju rezidencije Dužnika; 

Mandat mora sadržati standardno zaglavlje: „Direct Debit Mandate". 

Poleđina Mandata ne sme sadržati informacije koje se mogu pogrešno protumačiti kao deo 
Mandata. Poleđina Manadata može sadržati isti tekst kao i prednja strana Mandata, ali na 
drugomjeziku; 

Pravni tekst u Mandatu mora biti jasno izdvojen. 

3.1.8. Procesor može defmisati kao deo tehničkog uputstva, sadržaj i format obrasca Mandata u papirnom 
obliku, a Učesnici u kliringu prihvatiti njegovu upotrebu (Prilog 3. Sadržaj i format Mandata u papirnom 
obliku). 

Ukoliko pravni tekst u Mandatu nije moguće upisati u predviđeni prostor prihvaćenog formata obrasca 
Mandata zbog njegove dužine, može se dati u prilogu Mandata uz referisanje na prilog u delu Mandata 
predviđenom za pravni tekst. 

3.1.9. U okviru pružanja dodatnih usluga (AOS) Procesor može formirati i voditi Registar mandata u koji 
banke dužnika i poverioca mogu u svakom trenutku životnog ciklusa Mandata (i pre prvog ili jedinog 
dospeća) evidentirati Mandate svojih klijenata. Sadržaj poruka, njihova struktura i atributi za realizaciju 
dodatnih servisa vođenja Registra mandata kao i tehničko uputstvo za primenu i način dostavljanja 
poruka, defmiše Procesor i stavlja na raspolaganje svim Učesnicima 

3.1.10. Mandat se evidentira i čuva u Registru mandata u dematerijalizovanom obliku. 

3.1.11. Mandata koji se registruje u Registru mandata se jedinstveno identifikuje na nivou identifikacije 
poverioca (Creditorld) i identifikacije mandata (Mandateld). 

3.1.12. Jedistvenost identifikacije mandata obezbeđuje Poverilac. 

Poverilac može preneti svoju obavezu obezbeđenja jedinstvenosti identifikacije Mandata na drugo pravno 
lice (svoju banku, banku dužnika i dr.) pri čemu se identifikacija tog pravnog lica može navesti u strukturi 
identifikatora mandata (Mandateld) nakon, u tom slučaju, obavezne (npr: 1234-07123415, gde je 
1234 identifikacija mandata, 07123415 identifikacija pravnog lica koje je izdali identifikaciju mandata i 
garantuje njegovu jedinstvenost na nivou poverioca). 

3.1.13. Odgovornost za validnost Mandata kao i ispravnost podataka iz Mandata koje Učesnici 
dostavljaju Procesoru za upis u Registar mandata snose Učesnici. 

3.2. Struktura podataka Naloga za naplatu 

3.2.1. Struktura podataka kojom Poverilac inicira Direktno zaduženje u svojoj banci je defmisana DS-03 
strukturom SEPA pravila i sastoji se od podataka iz Mandata (struktura DS-02) i elemenata Naloga za 
naplatu koji su defmisani od strane Narodne Banke Srbije, Odlukom o obliku, sadržini i načinu korišćenja 
jedinstvenih instrumenata platnog prometa (Nalog za naplatu): 



Elementi Naloga za naplatu 

Mandatory/Optional 

1. 

Način izvršenja (inicijalno nalozi naplate nisu hitni) 

0 

2. 

ID Dužnika 

M 

3. 

Naziv Dužnika 

M 

4. 

Adresa Dužnika 

0 
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5. 

ID Poverioca 

M 

6. 

Naziv Poverioca 

M 

7. 

Adresa Poverioca 

0 

8. 

Broj računa Poverioca po IBAN standardu 

M 

9. 

Broj računa Dužnika po IBAN standardu 

M 

10. 

Oznaka valute (za domaću valutu: RSD) 

м 

11. 

Iznos zaduženja 

м 

12. 

Svrha plaćanja 

м 

13. 

Sifra plaćanja, u skladu sa vrstom ugovornog odnosa 

м 

14. 

Model poziva na broj zaduženja 

м 

15. 

Referenca Dužnika koja predstavlja Poziva na broj zaduženja 

м 

16. 

Model poziva na broj odobrenja 

0 

17. 

Referenca Poverioca koja predstavlja Poziva na broj odobrenja 

0 

18. 

Mesto podnošenja naloga 

м 

19. 

Datum podnošenja naloga 

м 

20. 

Datum realizacije (datum valute) 

м 

21. 

Overa naloga 

м 


3.2.2. Nalog za naplatu može biti ispostavljen u papirnom ili elektronskom obliku. 

3.2.3. Elemente zaštite i elektronski potpis Naloga za naplatu i Mandata ispostavljenog u elektronskom 
obliku utvrđuju Poverilac i Banka Poverioca, međusobno. 

3.2.4. Osnovna pravila u vezi sa formom i sadržinom Naloga za naplatu ispostavljenog u papirnom 
obliku: 

Sadržaj i format Naloga za naplatu u papirnom obliku je defmisan Odlukom o obliku, sadržini i 
načinu korišćenja jedinstvenih instrumenata platnog prometa (NBS); 

Jedinstveni identifikator Naloga za naplatu (ID transakcije) je obavezni element Naloga za 
naplatu, opredeljuje ga Banka Poverioca koja je dužna da obezbedi njegovu jedinstvenost na 
nivou Banke Poverioca; 

3.3. Struktura podataka instrukcije direktnog zaduženja 

3.3.1. Struktura podataka kojom Banka Poverioca inicira Direktno zaduženje kod Procesora je defmisana 
DS-04 strukturom SEPA pravila (Collection) i predstavlja set dematerijalizovanih podata iz struktura 
podataka DS-02 i DS-03: 



Elementi instrukcije 

Mandatory/Optional 

1 . 

ID Direct Debit šeme (SerbianDDCollection) 

M 

2. 

Datum realizacije (datum valute) 

M 

3. 

ID transakcije 

M 

4. 

Oznaka tipa transakcije u odnosu na tip Mandata 
(one-off; first; last; reccurent) 

M 

5. 

fznos zaduženja 

М 

6. 

Oznaka valute (za domaću valutu: RSD) 

М 

7. 

fznos obaveze u originalnoj (ugovorenoj) valuti 

0 

8. 

Oznaka originalne valute 

0 

9. 

Kurs za preračun iz originalne vahite u valutu plaćanja 

0 

10. 

Jedinstveni identifikator Mandata (ili Aneksa) po kome se 
ispostavlja Collection (na nivou Poverioca). 

м 

11. 

Datum ispostavljanja Mandata (verifikovanog) 

м 

12. 

Jedinstveni identifikator originalnog Mandata (ukoliko se 
Collection ispostavlja po Aneksu). 

0 

13. 

ID Poverioca (matični broj) 

м 

14. 

Naziv Poverioca 

м 

15. 

Adresa Poverioca 

0 

16. 

Sedište Poverioca (poštanski broj i grad) 

0 

17. 

Kod države rezidencije Poverioca (za Srbiju: RS) 

м 

18. 

Broj računa Poverioca po IBAN standardu 

м 

19. 

BIC Banke Poverioca 

м 

20. 

ID Dužnika (matični broj) 

м 

21. 

Naziv Dužnika 

м 

22. 

Adresa Dužnika 

0 
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23. 

Sedište Dužnika (poštanski broj i grad) 

0 

24. 

Kod države rezidencije Dužnika (za Srbiju: RS) 

M 

25. 

Broj računa Dužnika po IBAN standardu 

M 

26. 

BIC Banke Dužnika 

M 

26. 

Svrha plaćanja, 

м 

27. 

Referenca Poverioca koja predstavlja Poziva na broj odobrenja 

0 

28. 

Referenca Dužnika koja predstavlja Poziva na broj zaduženja 

м 

29. 

Referenca dokumenta ili naziv dokumenta predviđen Mandatom 

0 

30. 

Dodatna obrazloženja zaduženja 

0 


3.3.2. Instrukcija zaduženja (Collection) predstavlja elektronski oblik Naloga za naplatu i Mandata koji je 
dužnik predao svome poveriocu i svojoj banci. 

3.4. Struktura podataka za odbijanje i storno instrukcija Direktnog zaduženja 
3.4.1. Struktura podataka za kojom se vrši odbijanje instrukcije Direktnog zaduženja (Reject) i storniranje 
realizovane instrukcije Direktnog zaduženja (Return ili Refund) po osnovu ustanovljene greške, 
definisana je DS-05 strukturom SEPA pravila: 



Elementi instrukcije 

Mandatory/Optional 

1. 

ID instrukcije 

M 

2. 

ID originalne instrukcije zaduženja (Collection) 

M 

3. 

Tip instrukcije (Reject, Return, Refund Collection) 

M 

4. 

Oznaka inicijatora instrukcije (Banka Dužnika, Banka Poverioca 
ili Procesor za Reject, Banka Dužnika za Return i Dužnika za 
Refund) 

M 

5. 

Kod razloga neprihvatanja instrukcije zaduženja 

М 

6. 

Datum realizacije instrukcije (za Return i Refund) 

М 

7. 

Kopija svih atrubuta originalne instrukcije (struktura DS-04) 

М 


3.5. Struktura podataka za povraćaj sredstava 

3.5.1. Struktura podataka za iniciranje povraćaja sredstava od strane Poverioca ili Banke Poverioca po 
osnovu ustanovljene greške u realizovanoj instrukciji Direktnog zaduženjima (Reversal), defmisana je 
DS-07 strukturom SEPA pravila: 



Elementi instrukcije 

Mandatory/Optional 

1 . 

ID Reversal instrukcije 

M 

2. 

ID originalne instrukcije zaduženja (Collection) 

M 

3. 

Oznaka inicijatora Reversal instrukcije (Poverilca ili Banka 
Poverioca) 

M 

4. 

Broj računa Poverioca iz originalne instrukcije po IBAN 
standardu 

M 

5. 

BIC Banke Poverioca iz originalne 

М 

6. 

Datum realizacije Reversal instrukcije (datum valute) 

М 

7. 

Iznos za povraćaj Reversal instrukcijom 

М 

8. 

Oznaka valute (za domaću valutu: RSD) 

М 

9. 

Iznos za povraćaj u ugovorenoj valuti 

0 

10. 

Oznaka ugovorene valute 

0 

11. 

Kurs za preračun iz ugovorene valute u valutu plaćanja 

0 

12. 

Kod razloga povraćaj 

м 

13. 

Kopija svih atrubuta originalne instrukcije (struktura DS-04) 

м 
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TOKO VI 

3.6. Tokovi realizacije instrukcije direktnog zadužcnja 



3.7. Tokovi evidentiranja Mandata 



4. PROCESI 


4.1. Osnovni procesi Direktnih zaduženja (definisani SEPA pravilima) 



Proces 

SEPA oznaka 

1 . 

Mandate Issuing - Izdavanje Mandata 

PR-01 

2. 

Mandate Amendment - Izmena Mandata putem Aneksa 

PR-02 

3. 

Mandate Cancellation - Povlačenje Mandata 

PR-03 

4. 

Direct Debit - Realizacija Direktnog zaduženja 

PR-04 

5. 

Reversal - Povraćaj sredstava 

PR-05 


4.1.1. Osnovni koraci u procesu Izdavanja Mandata (PR-01) 


Oznaka 

koraka 

Korak 

Mandatory/ 

Optional 

PT-01.01 

Generisanje, verifikacija Mandata od strane dužnika u 
papirnom obliku i dostavljanje poveriocu 

M 

PT-01.02 

Generisanje, verifikacija i razmena Mandata između dužnika i 
poverioca u elektronskom obliku 

M 

PT-01.01a 

Dostavljanje Mandata banci dužnika od strane dužnika 

M 
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PT-01.02a 



PT-01.03 

Skladištenje (čuvanje) Mandata od strane poverioca 

M 

PT-01.06a 

Dostavljanje Mandata procesoru od strane banke poverioca 

O 

PT-01.06b 

Dostavljanje Mandata procesoru od strane banke dužnika 

O 

PT-01.07 

Dostavljanje informacija o Mandatu banci dužnika od strane 
Procesora 

O 

PT-01.08 

Odbijanje Mandata od strana banke dužnika 

O 

PT-01.09a 

Evidentiranje Mandata u Registru mandata Procesora 

O 

PT-01.09b 

Dostavljanje informacija o odbijanju Mandata banci poverioca 
od strane Procesora 

O 


4.1.2. Osnovni koraci u procesu Izmene Mandata (PR-02) 


Oznaka 

koraka 

Korak 

Mandatory/ 

Optional 

PT-02.01 

Generisanje, verifikacija Aneksa Mandata (Amendment) od 
strane dužnika u papirnom obliku ili elektronskom obliku i 
dostavljanje poveriocu 

M 

PT -02.01a 

Dostavljanje Aneksa Mandata banci dužnika od strane dužnika 

M 

PT-02.02 

Skladištenje Aneksa Mandata od strane poverioca 

M 

PT-02.06a 

Dostavljanje Aneksa Mandata Procesoru od strane banke 
poverioca 

O 

PT-02.06b 

Dostavljanje Aneksa Mandata Procesoru od strane banke 
dužnika 

O 

PT-02.07 

Dostavljanje informacija o Aneksu Mandata drugom učesniku 
(banci dužnika ili banci poverioca) 

O 

PT-02.08 

Odbijanje Aneksa Mandata od strana drugog učesnika (banke 
dužnika ili banke poverioca) 

O 

РТ -02.09a 

Evidentiranje Aneksa Mandata u Registru mandata 

O 

РТ -02.09b 

Dostavljanje informacija o odbijanju Aneksa Mandata banci 
podnosiocu (banci dužnika ili banci poverioca) 

O 


4.1.3. Osnovni koraci u procesu Povlačenja Mandata (PR-03) 


Oznaka 

koraka 

Korak 

Mandatory/ 

Optional 

PT-03.01 

Povlačenje Mandata od strane dužnika u papirnom ili 
elektronskom obliku i dostavljanje poveriocu 

M 

PT-03.01a 

Dostavljanje informacije o povlačenju Mandata banci dužnika od 
strane dužnika (Refusals) 

M 

PT-03.02 

Skladištenje informacije o povlačenju Mandata od strane 
poverioca 

M 

РТ-03.06а 

Dostavljanje informacije o povlačenju Mandata Procesoru od 
strane banke poverioca 

M 

PT-01.06b 

Dostavljanje informacije o povlačenju Mandata Procesoru od 
strane banke dužnika 

М 

РТ-01.07 

Dostavljanje informacije o povlačenju Mandata drugom učesniku 
od strane Procesora 

М 

РТ-01.08 

Evidentiranje promene statusa Mandata u Registru mandata 
Procesora 

М 

РТ-01.09 

Dostavljanje informacija o odbijanju promene statusa Mandata 
banci dužnika od strane Procesora 

М 


4.1.4. Osnovni koraci u procesu Direktnog zaduženja (PR-04) 


Oznaka 

koraka 

Korak 

Mandatory/ 

Optional 

РТ-04.01 

Generisanje Naloga za naplatu od strane Poverioca. 

M 

РТ-04.02 

Obaveštenje o datumu i iznosu dospeća obaveze. Obaveštenje 
upućuje Poverilac Dužniku. 

O 
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PT-04.02bis 

Podnošenje instrukcije za neizvršenjem Direktnog zaduženja, 
od strane Dužnika svojoj banci (Refusal) 

0 

PT-04.03 

Ispostavljanje Naloga za naplatu i Mandata, od strane 
Poverioca svojoj banci 

M 

PT-04.04 

Odbijanje Naloga za naplatu od strane Banke Poverioca, zbog 
neispravnosti iz tehničkih razloga i povraćaj Poveriocu 
(Reject) 

0 

PT-04.05 

Generisanje instrukcije Direktnog zaduženja (Collection) od 
strane Banke Poverioca i podnošenje Procesoru 

м 

PT-04.06 

Odbijanje Collection od strane Procesora, zbog neispravnosti 
iz tehničkih razloga i povraćaj Banci Poverioca (Reject) 

0 

РТ-04.07 

Ispostavljanje instrukcije Direktnog zaduženja, od strane 
Procesora Banci Dužnika (Collection) 

м 

РТ-04.08 

Odbijanje Collection od strane Banke Dužnika, zbog 
neispravnosti iz tehničkih razloga i povraćaj Procesoru 
(Reject) 

0 

РТ-04.08а 

Potvrda prihvatanja Collection od strane Banke Dužnika 

0 

РТ-04.09 

Zaduženje računa Dužnika od strane njegove banke po osnovu 
instrukcije Direktnog zaduženja 

м 

РТ-04.10 

Podnošenje instrukcije za storniranje realizovane instrukcije 
Direknog zaduženja, od strane Banke Dužnika Procesoru, po 
osnovu međubankarske reklamacije (Return) 

0 

РТ-04.11 

Podnošenje instrukcije za storniranje realizovane instrukcije 
Direknog zaduženja, od strane Procesora Banci Poverioca, po 
osnovu međubankarske reklamacije (Return) 

0 

РТ-04.12 

Zaduženje računa Poverioca od strane njegove banke po 
osnovu instrukcije za storniranje realizovane instrukcije 
Direktnog zaduženja ispostavljene po međubankarskoj 
reklamaciji (Return) 

0 

РТ-04.13 

Dužnik i Poverilac samostalno, bez uključenja banaka, 
rešavaju sporove koji mogu nastati zbog različitog tumačenja 
Mandata i neslaganja sa uslovima realizacije zaduženja 

0 

РТ-04.14 

Ukoliko je rešenje spora između Dužnika u Poverioca 
postignuto sporazumom kojim je predviđena dodatna naplata 
od strane Poverioca, ona se može realizovati podnošenjem od 
strane Poverioca svojoj banci sporazuma koji predstavlja 
aneks Mandat ili novi Mandati (Collection). 

0 

РТ-04.15 

Ukoliko je rešenje spora između Dužnika u Poverioca 
postignuto sporazumom kojim je predviđeno vraćanje 
sredstava Dužniku, on se može realizovati podnošenjem od 
strane Dužnika svojoj banci sporazuma koji predstavlja aneksa 
Mandata (Refund) ili novog Mandata (Collection). 

0 

РТ-04.16 

U postupku vraćanja sredstava Dužniku, Banka Dužnika 
upućuje Procesoru instrukciju za storniranje realizovane 
instrukcije zaduženja i povraćaj sredstava (Refund) 

0 

РТ-04.17 

Povraćaj sredstava se može izvršiti i na inicijativu Poverioca 
pri čemu Banka Poverioca podnosi Procesoru Instrukciju za 
povraćaj sredstava (Reversal) 

0 

РТ-04.18 

Pre ispostavljanja instrukcije za povraćaj sredstava Banka 
Poverioca vrši zaduženje računa Poverioca (Reversal) 

0 


4.1.5. Osnovni koraci u procesu Povraćaja sredstava (PR-05) 


Oznaka 

koraka 

Korak 

Mandatory/ 

Optional 

PT-05.01 

Generisanje Naloga za plaćanje od strane Poverioca i ispostavljenje 
Banci Poverioca. 

M 

PT -05.02 

Zaduženje računa Poverioca, generisanje instrukcije za povraćaja 
sredstava (Reversal) od strane Banke Poverioca i njeno 
ispostavljanje Procesoru. 

M 
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PT-05.03 

Uključenje ispostavljene instrukcije za povraćaj sredstava u Kliring 
i Obračun, od strane Procesora (CSMs) 

M 

PT-05.04 

Odobrenje računa Dužnika od strane Banke Dužnika po izvršenom 
Kliringu i Obračunu 

M 


4.2. Procesi za rešavanje izuzetaka i reklamacija 

4.2.1. Ukoliko se u procesima Direktnog zaduženja detektuje bilo kakav problem koji nije iz domena 
normalnog toka realizacije instrukcije Direktnog zaduženja (izuzetak), potrebno je pokrenuti odgovarajući 
proces za rešavanje izuzetka i to: 



Naziv procesa 

Opis 

1 . 

Revocation 

Zahtev za povlačenje Instrukcije Direktnog zaduženja, pre izvršenja ciklusa 
Kliringa koji podnosi Poverilac svojoj Banci. 

2. 

Request for 

cancellation 

Zahtev za povlačenje Instrukcije Direktnog zaduženja, pre izvršenja ciklusa 
Kliringa, koji podnosi Banka Poverioca Procesoru 

3. 

Refusal 

Zahtev Dužnika za neizvršenjem instrukcije Direktnog zaduženja iniciran pre 
ciklusa Kliringa, ispostavljen od strane Dužnika, Banci Dužnika, po opozivim 
Mandatima. 

Po ovom zahtevu Banka Dužnika je dužna da odbije sve instrukcije Direktnog 
zaduženje ispostavljene posle ispostavljanja Refusal zahteva (Reject). Na sve 
instrukcije Direktnog zaduženja koje su realizovane pre ispostavljanja Refusal 
zahteva, ovaj zahtev nema uticaja. 

Dužnik može ispostaviti Refusal zahtev kada su ispunjeni uslovi predviđeni 
zakonskim propisima (stečaj, likvidacija, smrt i dr.). 

4. 

Reject 

Odbijanje ispostavljene instrukcije Direktnog zaduženja pre ciklusa Kliringa i 
Obračuna zbog: 

Tehničkih razloga koji obuhvataju pogrešan format podataka, pogrešnu dužinu 
podataka, neispravne kontrolne cifre i dr. 

Nemogućnosti realizacije instrukcije Direktnog zaduženja iz razloga koji su 
razumljivi i prihvatljivi učesnicima (pre svega Dužniku i Poveriocu), a koji 
obuhvataju nedostatak sredstava na računu Dužnika, blokadu računa Dužnika i 
dr. 

Podnetog zahteva Dužnika za neizvršenjem instrukcije Direktnog zaduženja 
(Refusal) 

Realizuje se dostavljanjem međubankarske instrukcije za odbijanje instrukcije 
Direktnog zaduženja. 

5. 

Return 

Storniranje realizovane Instrukcije Direktnog zaduženja, nakon izvršenja 
instrukcije u ciklusu Kliringa i Obračuna, a po osnovu međubankarske 
reklamacije podnete u roku od 10 dana od dana izvršenja međubankarskog 
Obračuna. 

Realizuje se ispostavljenjem instrukcije za storniranje instrukcije Direktnog 
zaduženja od strane Banke Dužnika. 

6. 

Refund 

Storniranje realizovane Instrukcije Direktnog zaduženja, nakon izvršenja 
instrukcije u ciklusu Kliringa i Obračuna, a po osnovu reklamacije i 
sporazuma Dužnika i Poverioca. 

Realizuje se ispostavljenjem instrukcije za storniranje instrukcije Direktnog 
zaduženja od strane Banke Dužnika. 

7. 

Reversal 

Povraćaj sredstava nakon izvršenja instrukcije u ciklusu Kliringa i Obračuna, 
od strane Poverioca (ili Banke Poverioca), a po osnovu ustanovljene greške 
Poverioca (ili Banke Poverioca). 

Realizuje se ispostavljanjem instrukcije za povraćaj sredstava po realizovanoj 
instrukciji Direktnog zaduženja. 


4.2.2. Postupak reklamacije na realizovane instrukcije Direktnog zaduženja odnosi se na: 

Reklamacije na ciklus Kliringa i Obračuna 

o Obuhvataju reklamacije na Direktna zaduženja realizovana ili nerealizovana u ciklusu 
Kliringa i Obračuna, a koje se odnose na propuste nastale u samom ciklusu Kliringa ili 
Obračuna. 

o Podnose se Procesoru u roku od 10 dana od dana završetka ciklusa Kliringa i Obračuna. 
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o Odluku i rešenje po ovim reklamacijama donosi posebna komisija formirana u skladu sa 
Operativnim pravilima. 

o Realizuju se Return procesom na osnovu odluke Komisije, a pokreće ga Procesor. 

Međubankarske reklamacije 

o Obuhvataju sporove i reklamacije na Direktna zaduženja realizovana ili nerealizovana u 
ciklusu Kliringa i Obračuna, a koja se odnose na propuste učinjene od strane Učesnika i 
rešavaju ih međusobno Učesnici. 

o Učesnici mogu za ekspertizu i rešavanje sporova koristiti usluge posebna komisija 
formirane u skladu sa Operativnim pravilima, pri čemu se angažovanjem Komisije 
obavezuju za prihvatanje njene odluke po nastalom sporu. 
o Realizuju se Return procesom na osnovu sporazuma Učesnika ili odluke Komisije, a 
pokreće ga Banka Dužnika ili Reversal procesom koji pokreće Banka Poverioca. 

Reklamacije između Dužnika i Poverioca 

o Obuhvataju nejasna, sporna i različita tumačenja sadržaja Mandata od strane Dužnika i 
Poverioca i rešavaju ih međusobno Dužnik i Poverilac 
o Realizuju na osnovu sporazuma Dužnika i Poverioca, Refund procesom koji pokreće 
Banka Dužnika ili Reversal procesom koji pokreće Banka Poverioca. 

5.PORUKE 


5.1. Poruke za realizaciju instrukcija Direktnog zaduženja 



Poruka 

Oznaka poruke 

Oznaka 

strukture 

1 . 

Međubankarska instrukcija za odbijanje instrukcije Direktnog 
zaduženja (Reject) 

pacs.002.001.02 

DS-05 

2. 

Međubankarska instrukcija Direktnog zaduženja (Collection) 

pacs.003.001.01 

DS-04 

3. 

Međubankarska instrukcija za storniranje realizovane 
instrukcije Direktnog zaduženja (Return/Refund) 

pacs.004.001.01 

DS-05 

4. 

Međubankarska instrukcija za povraćaj sredstava po 
realizovanoj instrukciji Direktnog zaduženja (Reversal) 

pacs.007.001.01 

DS-07 


5.2. Poruke za međubankarski obračun. 

Za realizaciju međubankarskog obračuna u RTGS sistemu Procesor generiše i šalje poruke MT202 u 
SWIFT formatu, a u skladu sa telmičkim pravilima koja defmiše Narodna banka Srbije 


5.3. Ostale poruke Direktnog zaduženja: 



Poruka 

Oznaka poruke 

1 . 

Zahtev za povlačenje instrukcije Direktnog zaduženja (Request and 
cancellation) 

paos.002.001.01 

2. 

Izvod obračunskog računa Učesnika u Kliringu (Balance) 

paos.003.001.01 

3. 

Upit u status instrukcije Direktnog zaduženja (Collection Query) 

paos.006.001.01 

4. 

Odgovor na upit (Collection Response) 

paos.007.001.01 

5. 

Informacija o neto poziciji Učesnika u ciklusu Kliringa (Confirmation) 

paos.008.001.01 

6. 

Zahtev za postavljanje Limita zaduženja Učesnika (Limit) 

paos.009.001.01 


5.4. Administratorske poruke 



Poruka 

Oznaka poruke 

1 . 

Administratorska obaveštenje o sintaksnoj i tehničkoj neispravnosti 
poruke koja ne uključuju kontrole predviđene poslovnim pravilima 

admi.002.001.01 

2. 

Administratorska obaveštenja opšteg tipa (početak kliringa, kraj 
kliringa i dr.) 

admi.004.001.01 


5.5. Poruka transportnog nivoa 



Poruka 

Oznaka poruke 

1 . 

Potvrda uspešanog/neuspešnog prijema poruke 

ACKNAK 
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5.6. Г 

’oruke za realizaciju dodatnih servisa vođenja Registra mandata 



Poruka 

Oznaka poruke 

1 . 

Instrukcija za evidentiranje Mandata i izmenu Mandata u Registru mandata 

mndt.001.001.01 

2. 

Instrukcija za povlačenje Mandata iz Registra mandata 

mndt.002.001.01 

3. 

Instrukcija za odbijanje instrukcija za evidentiranje i izmenu Mandata. 

mndt.003.001.01 

4. 

Instrukcija za prihvatanje instrukcija za evidentiranje i izmenu Mandata 

mndt.004.001.01 

5. 

Zahtev za povlačenje instrukcija za evidentiranje, izmenu i povlačenje 
Mandata ( postojeće ) 

mndt.005.001.01 

6. 

Upit u sadržaj Registra mandata 

mndt.006.001.01 

7. 

Odgovor na upit 

mndt.007.001.01 


5.7. Sadržaj рошка, njihova struktura i atributi, kao i tehničko uputstvo za primenu i način dostavljanja 
poruka, defmiše Procesor i stavlja na raspolaganje svim Učesnicima. 

5.8. Komunikaciju i način dostavljanja informacija, instrukcija, naloga i dokumenata između banaka i 
njihovih klijenata (dužnici i poverioci) definišu banke i njihovi klijenti međusobno, uz preporuku da 
koriste strukture i poruke predviđene SEPA pravilima (npr. poruke tipa pain.xxx.xxx.xx) 

6. TEHNOLOŠKA PRAVILA 

6.1. Tehnološka pravila Registra mandata 

6.1.1. Registrovanje Mandata 

6.1.1.1. Banka dužnika i/ili banka poverioca može da podnese Procesoru zahtev za evidentiranje Mandata 
u Registar mandata u svakom trenutku njegovog životnog ciklusa, slanjem poruke sa instrukcijom za 
evidentiranje Mandata (mndt.001.001.01). 

6.1.1.2. Instrukcija za evidentiranje Mandata će biti odbijena od strane Procesora ukoliko je Mandat već 
evidentiran u Registru mandata, u bilo kom statusu. 

6.1.1.3. Svaki zahtev za evidentiranje Mandata upućen od strane banke poverioca, Procesor je dužan da 
uputi banci dužnika (originalnu instrukciju iz poruke mndt.001.001.01). 

6.1.1.3.1. U roku od 2 (dva) radna dana od dana dostavljanja instrukcije za evidentiranje Mandata, banka 
dužnika može: 

prihvatiti Mandat slanjem Procesoru poruke sa instrukcijom za prihvatanje Mandata 
(mndt.004.001.01) na osnovu koje Procesor odmah evidentira Mandat u Registar mandata, a 
banku poverioca obaveštava o registrovanom Mandatu upućivanjem originalne instrukcije za 
prihvatanje Mandata (mndt.004.001.01) 

eksplicitno odbiti Mandat slanjem poruke sa instrukcijom za odbijanje (mndt.003.001.01), koju 
Procesor odmah prosleđuje banci poverioca. 

6.1.1.3.2. U slučaju da u roku od 2 (dva) radna dana od dana dostavljanja instrukcije za evidentiranje 
Mandata banka dužnika ne izvrši prihvatanje ili odbijanje Mandata, Procesor će smatrati Mandat 
implicitno odbijenim i generisati i poslati banci poverioca instrukciju za odbijanje (mndt.003.001.01) sa 
obrazloženjem odbijanja. 

6.1.1.3.3. Period od 2 (dva) radna dana podrazumeva dva puna poslovna dana do početka klirinškog 
ciklusa u poslovnom dana u kome ističe rok za eksplicitno prihvatanje, odnosno odbijanje mandata. 

6.1.1.4. Instrukcije za evidentiranje Mandata upućene od strane banke dužnika, Procesor odmah 
evidentira u Registar mandata, a banku poverioca obaveštava o registrovanom Mandatu upućivanjem 
originalne instrukcije za evidentiranje Mandata (mndt.001.001.01). 

6.1.2. Izmena sadržaja Mandata 

6.1.2.1. Izmene sadržaja Mandata se mogu odnositi na uslove, ograničenja i prava defmisana Mandatom, 
a nikako na izmenu dužnika i poverioca. 

6.1.2.2. Banka dužnika i/ili banka poverioca mogu da podnesu Procesoru zahtev za evidentiranje izmene 
sadržaja Mandata u Registar mandata u svakom trenutku njegovog životnog ciklusa, slanjem poruke sa 
instrukcijom za evidentiranje izmene Mandata (mndt.001.001.01). 

6.1.2.3. Instrukcija za izmenu sadržaja Mandata, pored izmenjenih elemenata, mora sadržati i sve druge, 
neizmenjene podatke i informacije iz originalnog Mandata. 

U Registru mandata jedini važeći Mandat je Mandata evidentiran kroz poslednju instrukciju za izmenu 
Mandata.. 

6.1.2.4. Instrukcija za izmenu Mandata (mndt.001.001.01) će biti odbijena od strane Procesora ukoliko: 

Mandat nije evidentiran u Registru mandata 

Mandat je evidentiran u Registru mandata, ali je u neodgovarajućem statusu (nije aktivan) 

Izmena Mandata se odnosi na izmenu dužnika i/ili poverioca 
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Postoji neusklađenost datuma potpisa aneksa sa datumom potpisa originalnog mandata, odnosno 
prethodnog aneksa. 

Ukupan broj zaduženja predviđen izmenom Mandata je manji od broja realizovanih zaduženja 
Ukupan iznos zaduženja predviđen izmenom Mandata je manji od ukupno realizovanog iznosa 
zaduženja 

Izmenom Mandata je predviđena promena bilo kog kontrolnog elementa koji nije moguće 
primeniti od momenta izmene Mandata. 

6.1.2.5. Za svaku izmenu sadržaja Mandata moraju biti saglasni i dužnik i poverilac, odnosno banka 
dužnika i banka poverioca. 

6.1.2.6. Svaki zahtev za izmenu Mandata podnet od strane banke dužnika ili banke poverioca, Procesor je 
dužan da uputi drugoj banci (koja nije podnela zahtev) slanjem originalne instrukcije iz poruke 
mndt.001.001.01. 

6.1.2.6.1. U roku od 2 (dva) radna dana od dana dostavljanja instrukcije za izmenu Mandata, prijemna 
banka može: 

prihvatiti izmenu Mandat slanjem Procesoru poruke sa instrukcijom za prihvatanje izmene 
Mandata (mndt.004.001.01) na osnovu koje Procesor odmah evidentira izmenu Mandata u 
Registar mandata, a banku koja je ispostavila zahtev za evidentiranjem izmene Mandata, 
obaveštava upućivanjem originalne instrukcije za prihvatanje izmene Mandata 
(mndt.004.001.01). 

eksplicitno odbiti izmenu Mandat slanjem poruke sa instrukcijom za odbijanje 
(mndt.003.001.01), koju Procesor odmah prosleđuje banci koja je ispostavila zahtev za 
evidentiranjem izmene Mandata. 

6.1.2.6.2. U slučaju da u roku od 2 (dva) radna dana od dana dostavljanja instrukcije za evidentiranje 
izmene Mandata banka primalac ne izvrši prihvatanje ili odbijanje izmene Mandata, Procesor će smatrati 
izmenu Mandat implicitno odbijenom i generisati i poslati banci koja je ispostavila zahtev za 
evidentiranjem izmene Mandata instrukciju za odbijanje (mndt.003.001.01) sa obrazloženjem odbijanja. 

6.1.2.6.3. Period od 2 (dva) radna dana podrazumeva dva puna poslovna dana, do termina predviđenog za 
početak klirinškog ciklusa u poslovnom dana u kome ističe rok za eksplicitno prihvatanje, odnosno 
odbijanje izmene mandata. 

6.1.2.7. U procesu realizacije izmene Mandata, do uključenja izmene Mandata u Registar mandata, važeći 
(aktivan) je postojeći Mandata. 

6.1.3. Povlačenje Mandata 

6.1.3.1. Zahtev za povlačenje Mandata iz Registra mandata se može odnositi samo na osnovni Mandat, a 
nikako na povlačenje aneksa. Povlačenje Mandata obuhvata i povlačenje svih aneksa tog Mandata. 

6.1.3.2. Banka dužnika i/ili banka poverioca mogu da podnesu Procesoru zahtev za povlačenjem Mandata 
u svakom trenutku njegovog životnog ciklusa, slanjem poruke sa instrukcijom za povlačenjem Mandata 
(mndt.002.001.01). 

Banka dužnika može podneti Procesoru zahtev za povlačenjem Mandata samo u slučajevima predviđenim 
zakonom. 

6.1.3.3. Instrukcija za povlačenje Mandata (mndt.002.001.01) će biti odbijena od strane Procesora 
ukoliko: 

Mandat nije evidentiran u Registru mandata 

Mandat je evidentiran u Registru mandata, ali je u neodgovarajućem statusu (osnovni Mandat ili 
poslednji Aneksa nije aktivan) 

Zahtev za povlačenje se odnosi na Aneks, a ne na osnovni Mandat 

6.1.3.4. Instrukcije za povlačenje Mandata upućene od strane banke poverioca ili banke dužnika, Procesor 
odmah realizuje povlačenjem Mandata iz Registra mandata, a drugu banku obaveštava o povlačenju 
Mandata upućivanjem originalne instrukcije za povlačenje Mandata (mndt.002.001.01). 

6.1.3.5. U procesu realizacije povlačenja Mandata, do povlačenja Mandata iz Registra mandata, Mandat 
je u važećem statusu (aktivan). 

6.1.4. Povlačenje instrukcije za evidentiranje, izmenu i povlačenje Mandata 

6.1.4.1. Podnosilac instrukcije za evidentiranje, izmenu i povlačenje Mandata može bez obrazloženja 
izvršiti povlačenje ispostavljene instrukcije (Request and cancellation), dostavljanjem Procesoru poruke 
mndt.005.001.01. 

6.1.4.2. Instrukcija za povlačenje instrukcije (mndt.005.001.01) će biti odbijena od strane Procesora 
ukoliko je instrukcija za koju je podnet zahtev za povlačenje već realizovana. 

6.1.4.3. O povučenoj instrukciji Procesor obaveštava učesnika kome je upućena originalna instrukcija 
koja je povučena, dostavljanjem originalne instrukcije za povlačenje mndt.005.001.01. 

6.1.5. Upit u Registar mandata 
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6.1.5.1. Svaki Učesnik u Kliringu može u toku poslovnog dana, osim u vremenu predviđenom za 
realizaciju cilkusa Kliringa i Obračuna, od Procesora dobiti informacije o Mandatima u Registru mandata. 

6.1.5.2. Upit se inicira generisanjem poruke mndt.006.001.01 od strane Učesnika i njenim dostavljenjem 
Procesoru. 

6.1.5.3. Procesor realizuje upit na osnovu trenutnog stanja u evidenciji Registra mandata, shodno 
tehničkim mogućnostima u najkraćem mogućem roku, generisanjem poruke mndt.007.001.01 i 
dostavljenjem Učesniku koji je inicirao upit. 

6.1.6. Izveštavanje po instrukcijama Registra mandata 

6.1.6.1. Procesor je dužan da administratorskom porukom admi.002.001.01 (sa specificiranim razlozima 
odbijanja) odmah odbije u celosti poruku sa instrukcijama za Registar mandata zbog: 

tehničkih razloga koji obuhvataju pogrešan format ili strukturu poruke, eventualna tehnička 
ograničenja veličine poruke i sl.; 

razloga koji su vezani za neispravnosti podataka u zaglavlju poruke. 

6.1.6.2. Procesor je dužan da porukom mndt.003.001.01 (sa specificiranim razlozima odbijanja) odbije 
pojedinačne instrukcije za Registar mandata koje ne zadovolje kontrole defmisane tehničkim uputstvom, 
a koje obuhvataju: 

tehničke razloga (pogrešan format podataka, neispravne kontrolne cifre i sl.); 
kontrole koje proističu iz ugovorenih dodatnih servisa Procesora. 

Odbijene instrukcije zaduženja, Procesor označava u originalnoj poruci, u skladu sa Tehničkim 
uputstvom, pre dostave originalne poruke drugoj banci. 

6.2. Tehnološka pravila za realizaciju instrukcija direktnog zaduženja 

6.2.1. Evidentiranje instrukcije direktnog zaduženja kod Banke Poverioca 

6.2.1.1. Poverilac ispostavlja svojoj banci Nalog za naplatu zajedno sa Mandatom najmanje: 

4 (četiri) dana pre dospeća obaveze Dužnika za jednokratne Mandate i prvog dospeća po 
višekratnim Mandatima 

3 (tri) dana pre dospeća obaveze Dužnika za ostala dospeća (osim prvog) po višekratnim 
Mandatima. 

2 (dva) dana pre dospeća obaveze Dužnika za Mandate koji su evidentirani u Registru mandata 
Procesora i/ili u nespornom posedu Banke dužnika. 

Način dostavljanja Mandata i Naloga za naplatu definišu međusobno Banka Poverioca i Poverilac. 

6.2.1.2. Banka Poverioca može prihvatiti na realizaciju i Nalog za naplatu koji nije podnet u rokovima 
definisanim Operativnim pravilima, ali ne snosi odgovornost za odbijanje instrukcije zaduženja 
(Collection) od strane Dužnika po osnovu kašnjenja. 

6.2.1.3. Banka Poverioca proverava usklađenost podataka iz verifikovanog Mandata i ispostavljenog 
Naloga za naplatu i generiše instrukciju zaduženja (Collection) u skladu sa njima. 

6.2.1.4. Banka Poverioca ispostavlja Procesoru instrukciju zaduženja (Collection), dostavljanjem poruke 
pacs.003.001.01 najviše 15 (petnaest) dana pre datuma njenog dospeća, a najmanje: 

3 (tri) dana pre dospeća obaveze Dužnika za jednokratne Mandate i prvog dospeća po 
višekratnim Mandatima, 

2 (dva) dana pre dospeća obaveze Dužnika za ostala dospeća (osim prvog) po višekratnim 
Mandatima, 

1 (jedan) dan pre dospeća obaveze Dužnika za Mandate koji su evidentirani u Registru mandata 
Procesora i/ili u nespornom posedu Banke dužnika 

Dostavljanjanje instrukcije zaduženja (Collection) Banka Poverioca vrši u skladu sa Terminskim planom 
Procesora 

6.2.1.5. Banka Poverioca može na zahtev Poverioca (Revocation), bez obrazloženja izvršiti povlačenje 
(Request and cancellation) ispostavljene instrukcije zaduženja (Collection), dostavljanjem Procesoru 
poruke paos.002.001.01, do termina predviđenog Terminskim planom za realizaciju ciklusa Kliringa za 
datum naveden u instrukciji zaduženja (Collection). Procesor će izvršiti zahtev Banke Poverioca za 
povlačenje instrukcije zaduženja (Collection), bez obzira na njegov trenutni status (prihvaćenost od strane 
Banke dužnika). 

O povučenoj instrukciji Procesor obaveštava Banku Dužnika dostavljanjem originalne instrukcije za 
povlačenje paos.002.001.01. 

6.2.2. Evidentiranje instrukcije direktnog zaduženja kod Procesora 

6.2.2.1. Procesor evidentira instrukciju zaduženja (Collection) i ispostavlja je Banci Dužnika 
dostavljanjem originalne poruke pacs.003.001.01 najmanje: 

2 (dva) dana pre dospeća obaveze Dužnika za jednokratne Mandate i prvog dospeća po 
višekratnim Mandatima, 
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1 (jedan) dan pre dospeća obaveze Dužnika za ostala dospeća (osim prvog) po višekratnim 
Mandatima i za Mandate koji su evidentirani u Registru mandata Procesora i/ili u nespornom 
posedu Banke dužnika. 

6.2.2.2. Procesor je dužan da administratorskom porukom admi.002.001.01 odmah odbije sve instrukcije 
zaduženja (Collection), odnosno poruku u celosti, u zbog: 

razloga koji su vezani za neispravnosti podataka u zaglavlju poruke (neispravni računi Banke 
dužnika ili Banke poverioca, status računa Banke Dužnika i/ili Banke Poverioca kod Procesora i 
u RTGS sistemu, a koji obuhvataju blokadu računa Banke Dužnika i/ili Banke Poverioca, 
isključenje iz kliringa Banke Dužnika i/ili Banke Poverioca, neispravne kontrolne sume i sl.) 
drugih, tehničkih razloga koji obuhvataju pogrešan format ili strukturu poruke, eventualna 
tehnička ograničenja veličine poruke i sl. 

6.2.2.3. Procesor je dužan da porukom pacs.002.001.02 (Reject) odbije one instrukcije zaduženja 
(Collection) koje ne zadovolje kontrole definisane tehničkim uputstvom, a koje obuhvataju: 

tehničke razloga (pogrešan format podataka, neispravne kontrolne cifre i sl.) 
kontrole koje proističu iz ugovorenih dodatnih servisa Procesora 
Odbijene instrukcije zaduženja, Procesor označava u originalnoj poruci, u skladu sa Tehničkim 
uputstvom, pre dostave originalne poruke banci Dužnika. 

6.2.2.4. Procesor može na osnovu informacija u Registru mandata pružiti učesnicima dodatne sevise u 
realizaciji direktnih zaduženja koji se odnose na: 

Kontrolu Mandata u Registru mandata (evidentiranosti i statusa) 

Kontrolu usklađenosti sadržaja instrukcije direktnog zaduženja (Collection) sa struktuiranim 
informacijama iz dematerijalizovanog oblika Mandata, evidentiranim u Registru mandata 

6.2.2.4.1. Kontrola Mandata u Registru mandata (evidentiranosti i statusa) obuhvata: 

Kontrolu postojanja Mandata u evidenciji Registra mandata 

Ukoliko Mandat nije evidentiran u Registru mandata Procesora, realizacija instrukcije direktnog 
zaduženja će biri sprovedena prema tehnološkom postupku defmisanom Osnovnim uputstvom. 
Ukoliko je Mandat registrovan u evidenciji Registra mandata, vrši se kontrola statusa Mandata 
Ukoliko Mandat nije u aktivnom statusu, Procesor će odbiti podnetu instrukciju direktnog 
zaduženja (Collection) slanjem podnosiocu Reject instrukcije. 

Ukoliko je Mandat evidentiran u Registru mandata i u aktivnom statusu, Procesor će izvršiti 
kontrolu usklađenosti sadržaja instrukcije direktnog zaduženja (Collection) sa evidentiranim 
Mandatom. 

6.2.2.4.2. Kontrola usklađenosti sadržaja instrukcije direktnog zaduženja i evidentiranog Mandata 
obuhvata: 

Kontrolu dužnika i poverioca. 

o Provera usklađenosti podataka o dužniku i poveriocu. 

Kontrolu datuma dospeća. 

o Datum dospeća iz instrukcije zaduženja ne može biti manji od datuma dospeća prvog 
zaduženja niti veći od datuma isteka mandata definisanog u evidentiranom Mandatu. 
o Datum dospeća iz instrukcije zaduženja mora biti u skladu sa datom metrikom, odnosno 
sa fiksnim datumom dospeća, uz poštovanje nivoa tolerancije, defmisanog u 
evidentiranom Mandatu. 

Kontrolu ugovorne valute. 

o Ugovorna valuta u instrukciji zaduženja mora biti usklađena sa ugovornom valutom 
defmisanom u evidentiranom Mandatu. 

o Preračun u valutu plaćanja (RSD) u instrukciji zaduženja mora biti izvršen prema 
pravilima (kurs, kursna lista) definisanim u evidentiranom Mandatu. 

Kontrolu iznosa zaduženja. 

o Iznos zaduženja iz instrukcije zaduženja ne može bii veći od iznosa maksimalnog 
pojedinačnog zaduženja defmisanog u evidentiranom Mandatu 
o Ukupan iznos realizovanih zaduženja po Mandatu sa uključenim iznosom zaduženja iz 
instrukcije zaduženja ne može biti veći od ukupnog iznosa zaduženja defmisanog u 
evidentiranom Mandatu 

6.2.2.5. Kontrola se vrši na osnovu struktuiranih podataka Mandata koji su evidentirani u Registru 
mandata. 

Za opcione podatke koji nisu dati u Mandatu, kontrola se ne vrši. 

6.2.2. 6 . Kontrole instrukcija zaduženja na osnovu informacija iz Registra mandata je opciona, što znači da 
učesnik, u svojstvu banke dužnika, može izabrati da li želi: 

Samostalno vršenje svih kontrola (statusa i usklađenosti Mandata i instrukcije zaduženja) 
nezavisno od evidentiranosti u Registru mandata; 
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Potpunu kontrolu Procesora, koja podrazumeva odbijanje instrukcija koje ne zadovoljavaju 
kontrolu usklađenosti Mandata i instrukcije zaduženja za Mandate evidentirane u Registru 
mandata odbijanje i odbijanje svih instrukcija po Mandatima koji nisu evidentirani u Registru 
mandata; 

Parcijalnu kontrolu Procesora, koja podrazumeva odbijanje instrukcija koje ne zadovoljavaju 
kontrola usklađenosti Mandata i instrukcije zaduženja, za Mandate evidentirane u Registru 
mandata i dostavljanje učesniku instrukcija po Mandatima koji nisu evidentirani u Registru 
mandata. 

6.2.2.7. Procesor je dužan da uključi u ciklus Kliringa sve instrukcije Direktnog zaduženja koje nisu 
odbijene. 

6.2.3. Evidentiranje instrukcije direktnog zaduženja kod Banke Dužnika 

6.2.3.1. Banka Dužnika evidentira Collection i obaveštava svog klijenta - Dužnika o dospelom 
Collection-u. 

Obaveznost obaveštavanja o dospelom Collection-u, način i rokove obaveštavanja Dužnika od strane 
Banke Dužnika, definišu Banka Dužnika i Dužnik međusobno. 

6.2.3.2. Dužnik može dostaviti Banci Dužnika zahtev za neizvršenje instrukcije Direktnog zaduženja 
(Refusal), sa obrazloženjem i zakonskim osnovom za opoziv Mandata, do termina predviđenog za 
realizaciju ciklusa Kliringa za datum naveden u Collection-u, odnosno do termina predviđenog poslovnim 
terminskom planom Banke Dužnika koji mora biti usklađen sa terminskim planom Procesora. 

6.2.3.3. Banka dužnika može odbiti realizaciju Direktnog zaduženja po Collection-u (Reject) 
dostavljanjem Procesoru poruke pacs.002.001.02 do termina predviđenog terminskim planom za 
realizaciju ciklisa Kliringa za datum naveden u Collection-u zbog: 

nemogućnosti realizacije Collection-a iz razloga koji su vezani račun Dužnika, a koji obuhvataju 
blokadu računa Dužnika i nedostatak sredstava na računu Dužnika. 

podnetog zahteva Dužnika za neizvršenjem instrukcije Direktnog zaduženja zbog opoziva 
Mandata (Refusal) 

drugih, tehničkih razloga koji obuhvataju pogrešan format podataka, neispravne kontrolne cifre i 
sl. 

Ukoliko Banka Dužnika ne obavesti Procesora o odbijanju Collection-a, smatra se da je Collection 
prihvaćen i može biti uključen u ciklus Kliringa. 

6.2.3.4. Banka dužnika je dužna da u slučaju nemogućnosti realizacije instrukcije direktnog zaduženja 
(Collection) zbog nedostatka sredstava i/ili blokade računa dužnika (Reject), inicira proces prinudne 
naplate u skladu sa zakonskim propisima, slanjem odgovarajuće poruke organizaciji za sprovođenje 
postupka prinudne naplate (poruka MT998 kao omotnica za poruku sopstvenog formata SMT710) sa 
podacima iz instrukcije zaduženja (Collection). 

6.2.4. Izveštavanje po instrukcijama direktnog zaduženja 

6.2.4.1. Procesor može odbiti realizaciju instrukcija Direktnog zaduženja zbog: 

odbijanja Banke dužnika da realizacije Direktno zaduženja po Collection-u (Reject banke 
dužnika) 

nemogućnosti realizacije Collection-a iz razloga koji su vezani za račun Banke dužnika kod 
Procesora i u RTGS sistemu, a koji obuhvataju nedostatak sredstava na računu Banke dužnika, 
blokadu računa Banke dužnika, nedovoljnog Limita, isključenja iz kliringa Banke dužnika i dr. 
nemogućnosti realizacije Collection-a iz razloga koji su vezani za status računa Banke poverioca 
kod Procesora i u RTGS sistemu, a koji obuhvataju blokadu računa Banke poverioca, isključenje 
iz kliringa Banke poverioca i dr. 

6.2.4.2. Procesor je dužan da pre realizacije ciklusa Kliringa dostavi učesnicima poruke pacs.002.001.02 
sa obaveštenjem o odbijanju instrukcija Direktnog zaduženja, za sve Collectione koji nisu uključeni u 
ciklus Kliringa za datum naveden u Collection-u. 

6.2.4.3. Procesor je dužan da po izvršenom ciklusu Kliringa, a pre realizacije obračuna u RTGS sistemu, 
obavesti Učesnike o neto pozicijama u kliringu dostavljanjem poruke paos.008.001.01 (Confirmation). 

6.2.4.4. Procesor je dužan da nakon izvršenog Obračuna u RTGS sistemu, obavesti Učesnike o svim 
realizovanim Direktnim zaduženjima preko obračunskog računa Učesnika koji se vodi kod Procesora, 
dostavljanjem Učesnicima kliringa poruke paos.003.001.01 sa izvodom obračunskog računa (Balance). 

6.3. Tehnološka pravila za realizaciju ciklus Kliringa i Obračuna 

6.3.1. Ciklus Kliringa za instrukcije Direktnog zaduženja čije je dospeće narednog dana Procesor 
sprovodi jednom dnevno u skladu sa Terminskim planom za Kliring i Obračun po Direktnim 
zaduženjima, a nakon zatvaranja RTGS sistema za prijem naloga za plaćanje. 

6.3.2. Učesnici u kliringu i obračunu su dužni da obezbede Procesoru informaciju o maksimalnom iznosu 
zaduženja njihovog računa u RTGS sistemu (u daljem tekstu: Limit zaduženja). 
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6.3.3. Dostavljanje Limita zaduženja Procesoru, Učesnici vrše porukom paos.009.001.01. 

Važeći Limit zaduženja, koji Procesor koristi u ciklusu Kliringa, je Limit zaduženja dostavljen u 
poslednjoj paos.009.001.01 poruci. 

6.3.4. Razlika u finansijskom iznosu između sume iznosa podnetih (prilivi) i sume iznosa primljenih 
(odlivi) instrukcija Direktnog zaduženja sa računa klijenata jednog Učesnika predstavlja njegovu Neto 
poziciju koja može biti pozitivna (više priliva nego odliva), negativna (više odliva nego priliva) i nulta 
(jednako odliva i priliva). 

Učesnici su dužni da obezbede na računu u RTGS sistemu dovoljno sredstava za realizaciju negativne 
Neto pozicije, odnosno da dostavljanjem Limita zaduženja u skladu sa stanjem na računu u RTGS 
sistemu, obezbede da njegova negativna Neto pozicija bude realizovana u Obračunu. 

6.3.5. Procesor sprovodi ciklus Kliringa u sledećim koracima: 

Izračunavanje Neto pozicija. 

o Vrši se na nivou obračunskih računa Učesnika u kliringu, njihovim zaduženjem i 
odobrenjem u skladu sa svakom verifikovanom instrukcijom zaduženja. Stanje 
obračunskog računa Učesnika po završetku obračuna predstavlja njegovu Neto poziciju. 
Primena Limita zaduženja. 

o Za svakog Učesnika kod koga je negativna Neto pozicija veća od Limita zaduženja, 
Procesor vrši odbijanje instrukcija zaduženja koje se odnose na zaduženje njegovog 
računa, prema iznosu zaduženja (od najvećeg ka najmanjem), a do nivoa negativne 
Neto pozicije jednake ili manje od Limita zaduženja, uz ponavljanje ciklusa Kliringa 
(korak pod a., bez odbijenih instrukcija Direktnog zaduženja). 
o odbijenim Direktnim zaduženjima Procesor odmah obaveštava učesnike slanjem poruka 
pacs.002.001.02 (Reject) 

Verifikacija ciklusa Kliringa. 

o Procesor vrši verifikaciju ciklusa Kliringa na taj način što za svakog Učesnika sa 
negativnom Neto pozicijom u kliringu (u koracima pod a. i b.) obezbeđuje od RTGS 
sistema potvrdu da na njegovom računu u RTGS sistemu ima dovoljno sredstava za 
realizaciju obračunate negativne Neto pozicije. 
o Procesor isključuje iz ciklusa Kliringa svakog Učesnika koji nema dovoljno sredstava 
na računu u RTGS sistemu za realizaciju obračunate negativne Neto pozicije, vrši 
odbijanje svih instrukcija Direktnog zaduženja koje se odnose na njega (zaduženja i 
odobrenja), uz ponavljanje ciklusa Kliringa (korak pod a., bez odbijenih instrukcija 
Direktnog zaduženja). 

o odbijenim Direktnim zaduženjima Procesor odmah obaveštava Banke Poverioca 
slanjemporuka pacs.002.001.02 (Reject Collection) 

6.3.6. Obračun za verifikovani ciklus Kliringa, Procesor sprovodi na dan dospeća, odmah po otvaranju 
RTGS sistema za prijem naloga za plaćanje. 

6.3.7. Procesor realizuje Obračun preko svog obračunskog računa i računa Učesnika u RTGS sistemu, 
porukama MT202 u swift formatu defimsanim ovim Uputstvom, koje dostavlja i realizuje u RTGS 
sistemu u sledećem redosledu: 

Sve poruke za realizaciju negativne Neto pozicije, kojima se vrši zaduženje računa Učesnika sa 
negativnom Neto pozicijom u ciklusu Kliringa i odobrenje obračunskog računa Procesora 
Sve poruke za realizaciju pozitivne Neto pozicije, kojima se vrši zaduženje obračunskog računa 
Procesora i odobrenje računa Učesnika sa pozitivnom Neto pozicijom u ciklusu Kliringa. 

6.4. Tehnološka pravila za realizaciju izuzetaka i rekiamacija 

6.4.1. Po ustanovljenoj grešci u realizovanoj instrukciji Direktnog zaduženja, povraćaj sredstava sa 
računa Poverioca i/ili Banke Poverioca mogu inicirati: 

Poverilac ili Banka Poverioca, u bilo kom trenutku nakon ciklusa Kliringa i Obračuna u kome je 
realizovana instrukcija Direktnog zaduženja (Reversal). 

o Povraćaj sredstava se realizuje generisanjem pacs.007.001.01 od strane Banke 
Poverioca i njenim slanjem Procesoru koji je uključuje u odgovarajući ciklus Kliringa. 
Procesor, po odluci Komisije za rešavanje reklamacija koje se odnose na propuste nastale u 
ciklusu Kliringa i Obračuna, i međubankarske reklamacije, podnete u roku od 10 dana od dana 
ciklusa Kliringa i Obračuna u kome je realizovana instrukcija Direktnog zaduženja (Return). 

o Povraćaj sredstava se realizuje generisanjem poruke pacs.004.001.01 od strane 
Procesora i njenim uključenjem u odgovarajući ciklus Kliringa. 

Dužnik ili Banka Dužnika, na osnovu sporazuma Dužnika i Poverioca ili Banke Dužnika i Banke 
Poverioca u bilo kom trenutku nakon ciklusa Kliringa i Obračuna u kome je realizovana 
instrukcija Direktnog zaduženja (Refund). 
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o Povraćaj sredstava se realizuje generisanjem pacs.004.001.01 od strane Banke Dužnika 
i njenim slanjem Procesoru koji je uključuje u odgovarajući ciklus Kliringa po istom 
tehnološkom postupku koji se primenjuje za Collection (pacs.003.001.01), sa 
izmenjenim ulogama učesnika (Poverilac:Dužnik, Banka Poverioca:Banka Dužnika). 

6.4.2. Procesor je dužan da evidentira instrukcije za realizaciju izuzetaka i reklamacija. 

6.4.3. Procesor je dužan da administratorskom porukom adm.002.001.01 odmah odbije sve instrukcije za 
realizaciju izuzetaka i reklamacija, odnosno primljene poruke u celosti, u zbog: 

razloga koji su vezani za neispravnosti podataka u zaglavlju poruke (neispravni računi Banke 
dužnika ili Banke poverioca, status računa Banke Dužnika i/ili Banke Poverioca kod Procesora i 
u RTGS sistemu, a koji obuhvataju blokadu računa Banke Dužnika i/ili Banke Poverioca, 
isključenje iz kliringa Banke Dužnika i/ili Banke Poverioca, neispravne kontrolne sume i sl.) 
drugih, tehničkih razloga koji obuhvataju pogrešan format ili strukturu poruke, evevntualna 
tehnička ograničenja veličine poruke i sl. 

6.4.4. Procesor je dužan da porukom pacs.002.001.02 (Reject) odmah odbije one za realizaciju izuzetaka 
i reklamacija koje ne zadovolje kontrole defmisane tehničkim uputstvom, a koje obuhvataju: 

tehničke razloga (pogrešan format podataka, neispravne kontrolne cifre i sl.) 
kontrole koje proističu iz ugovorenih dodatnih servisa Procesora 
Odbijene instrukcije zaduženja, Procesor označava u originalnoj poruci, u skladu sa Tehničkim 
uputstvom, pre dostave originalne poruke drugom učesniku. 

6.5. Ostali servisi 

6.5.1. Svaki Učesnik u Kliringu može u toku poslovnog dana, osim u vremenu predviđenom za realizaciju 
cilkusa Kliringa i Obračuna, od Procesora dobiti informacije o podnetim instrukcijama Direktnog 
zaduženja u kojima se Učesnik javlja u svojstvu Dužnika, Banke Dužnika, Poverioca ili Banke Poverioca. 
Upit se inicira generisanjem poruke paos.006.001.01 od strane Učesnika i njenim dostavljenjem 
Procesoru (Collection Query). 

6.5.2. Procesor realizuje upit, shodno tehničkim mogućnostima u najkraćem mogućem roku, 
generisanjem poruke paos.007.001.01 i dostavljenjem Učesniku koji je inicirao upit (Collection 
Response). 

6.5.3. Procesor može u okviru dodatnih opcionih servisa (AOS - Additional Optional Service) ponuditi 
Učesnicima pružanje i drugih usluga (vođenje evidencija, izveštavanje klijenata i dr.) u skladu sa unapred 
defmisanim pravilima prihvaćenim od strane Učesnika i Procesora. 
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Prilog 3: 

TERMINSKI PLAN ZA SISTEM KLIRINGA I OBRAČUNA PO DIREKTNIM 
ZADUŽENJIMA 

Radno vreme Kliringa i Obračuna 

Radno vreme Procesora za realizaciju poslova kliringa i obračuna po Direktnim zaduženjima je od 8.00 
do 22.00 časova. 

Dnevni terminski plan Kliringa i Obračuna 

Dnevni terminski plan rada Procesora za prijem i slanje poruka, Kliring i realizaciju Obračuna u RTGS 
sistemu je: 


Opis poslovnog procesa 

Oznaka 

poruke 

Dnevni 

termin 

realizacije 

Razmena poruka sa instrukcijama Direktnog zaduženja, za uključenje 
u ciklus Kliringa koji se odnosi na dospeća narednog dana 

pacs.003.001.01 

pacs.004.001.01 

pacs.007.001.01 

09.00- 17.00 

Razmena poruka sa instrukcijama Direktnog zaduženja, za uključenje 
u ciklus Kliringa koji se odnosi na dospeća ostalih dana posle 
narednog dana, a najduže 15 dana pre dospeća 

pacs.003.001.01 

pacs.004.001.01 

pacs.007.001.01 

09.00- 19.00 

Razmene poruka za povlačenje podnetih instrukcija Direktnog 
zaduženja 

paos.002.001.01 

09.00- 18.00 

Razmene poruka za odbijanje instrukcija Direktnog zaduženja 

paos.002.001.02 

09.00- 18.00 

Razmena porukama za upit u status instrukcija od strane Učesnika i 
odgovor Procesora 

paos.006.001.01 
paos.007.001.01 

09.00- 19.00 

Dostava рошка za promenu/postavljanje Limita zaduženja Učesnika 

paos.009.001.01 

09.00- 19.00 

Realizacija ciklusa Kliringa za instrukcije sa dospećem narednog dana, 
koja obuhvata i proveru usaglašenosti Limita zaduženja i negativne 
Neto pozicije Učesnika sa stanjem na računu Učesnika u RTGS 
sistemu 


19.00-21.00 

Dostava рошка sa informacijama o neto poziciji Učesnika u ciklusu 
Kliringa realizovanom za tekući dan kao datum dospeća, a pre 
realizacije Obračuna 

paos.008.001.01 

08.00-09.00 

Realizacija Obračuna u RTGS sistemu po ciklusu Kliringa 
realizovanom za tekući dan kao datum dospeća 

MT202 

09.00- 10.00 

Dostava izvoda obračunskog računa Učesnika u ciklusu Kliringa 
realizovanom za tekući dan kao datum dospeća, u danu u kome je 
realizovan Obračun 

paos.003.001.01 

10.00-12.00 

Dostava administrativnih рошка Procesora 

admi.002.001.01 

admi.004.001.01 

08.00-21.00 


Procesor može započeti obračun u ciklusu Kliringa po završetku prijema naloga za plaćanje u RTGS 
sistemu, što znači da će u slučaju produženja rada RTGS sistema za prijem naloga za plaćanje, dnevni 
terminski plan rada Procesora u delu realizacije ciklusa Kliringa biti pomeren za vreme produženja rada 
RTGS sistema. 


Dnevni terminski plan za dodatne servise 

Dnevni terminski plan rada Procesora sa Registrom mandata je: 


Opis poslovnog procesa 

Oznaka 

Poruke 

Dnevni termin 
realizacije 

Razmena рошка sa instrukcijama za evidentiranje i 
izmenu Mandata u Registru mandata 

nmdt. 001.001.01 

09.00- 17.00 

Razmene poruka za povlačenje Mandata iz Registra 
mandata 

nmdt. 002.001.01 

09.00- 17.00 

Razmene poruka za odbijanje instrukcija za 
evidentiranje i izmenu Mandata 

mndt.003.001.02 

09.00- 18.00 

Razmene poruka za prihvatanje i izmenu Mandata 

mndt.004.001.01 

09.00- 18.00 

Razmene poruka za povlačenje podnetih instrukcija 

nmdt. 005.001.01 

09.00- 18.00 

Razmena poruka za upit u sadržaj Registra mandata od 
strane Učesnika i odgovor Procesora 

mndt.006.001.01 

nmdt.007.001.01 

09.00- 18.00 

Dostava administrativnih poruka Procesora 

admi.002.001.01 

09.00- 19.00 
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Prilog 4. 

M A N D A T, Sadrzaj i forma 

SEPA Direct Debit Mandate Broj ovlašćenja: 


Broj ugovora: 


Potpisom ove forme dužnik daje ovlašćenje: 

(A) Poveriocu da ispostavi instrukciju za zaduženje računa dužnika u skladu sa uslovima navedenim u 
ovlašćenju; 

(B) Banci dužnika da zadužuje račun dužnika u skladu sa instrukcijama poverioca, sa pravom da izvrši 
rezervaciju potrebnih sredstava na računu dužnika pre realizacije međubankarskog plaćanja. 

Prava dužnika i poverioca koja se odnose na reklamacije po osnovu realizovanih plaćanja, kao i rokovi i 
način povraćaj sredstava su definisani Operativnim pravilima za realizaciju direktnih zaduženja koja se 
mogu dobiti od banke. 

D U Ž N I K: _ 

Sedište i adresa: _ 

Matični broj: _ Poreski broj: 


POVERILAC: _ 

Sedište i adresa: _ 

Matični broj: _ 

USLOVI PLAĆANJA 
Datum dospeća prve obaveze: 

Ukupan broj obaveza po ovlašćenju: 

Ukupni iznos obaveza po ovlašćenju: 

Iznos pojedinačnih obaveza: 

DODATNI USLOVI DOSPEĆA: 


Poreski broj: 

Datum isteka ovlašćenja: 
Periodika dospeća: 

Sifra valute: 
Šifra valute: 


OPOZIVOST IUSLOVI OPOZIVOSTI OVLAŠĆENJA: 

Neopozivo do datuma isteka, osim u slučajevima predviđenih zakonom. 

BANKA DUŽNIKA: _ 

BROJ RAČUNA DUŽNIKA: _ 

Datum izdavanja ovlašćenja: _ 


IZDAVALAC OVLAŠĆENJA 


BANKA DUŽNIKA 


_ votvis ovl. lica i večat dužnika _ votvis ovl. lica i večat banke 

dužnika 

Ime, prezime i JMBG ovl. lica dužnika Ime i prezime ovl. lica i BIC banke 

dužnika 
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Prilog 5: 

TEHNIČKO UPUTSTVO 

ZA PORUKE DIREKTNOG ZADUŽENJA 

PORUKA pacs.003.001.01 COLLECTION 
Struktura: SerbianCollection 

• Koristi se za iniciranje i izvršenje transakcija direktnog zaduženja 

• Generiše je banka poverioca i Ispostavlja procesoru 

• Poruka se sastoji od zaglavlja (Group Header) koje nosi zajedničke informacije svih transkacija 
direktnog zaduženja iz poruke i tela poruke (Transaction Information) koje nosi informacije o 
pojedinačnim transakcijama direktnog zaduženja koje banka inicira. 

• Struktura poruke: 


Index 

Kardina 

lnost 

Element poruke 

Tip 

Opis i poslovna pravila 

1.0 

M 1 

+ 

Header 

GroupHeader20 

Zaglavlje poruke 

1.1 

M 1 

+ 

+ 

Messageld 

Max35Text 

Jedinstveni identifikator 
poruke koji formira 
pošiljalac poruke. 

1.2 

M 1 

+ 

+ 

CreationDate 

ISODateTime 

Datum kreiranja poruke. 

1.5 

M 1 

+ 

+ 

NumberTransaction 

Maxl 5NumericText 

Ukupan broj transakcija u 
poruci 

1.7 

М 1 

+ 

+ 

TotalAmount 

EuroMaxl 5 Amount 

Ukupan iznos transakcija 
u poruci 

1.7 

М 1 

+ 

+ 

+ 

Amount 

Decimal, 15,2 

Ukupan iznos transakcija 
u poruci 

1.7 

М 1 

+ 

+ 

+ 

Сиггепсу Code 

EuroCurrencyCode 

Kod domaće valute: RSD 

1.8 

М 1 

+ 

+ 

SettlementDate 

ISODate 

Datum međubankarskog 
obračuna 

1.9 

М 1 

+ 

+ 

Settlementlnformation 

Settlementlnformation 

12 

Informacije o obračunu 

1.10 

М 1 

+ 

+ 

+ 

SettlementMethodCode 

SettlementMethod2Co 

de 

Vrednost: CLRG 

1.12 

М 1 

+ 

+ 

+ 

ClearingSystem 

ClearingSystemIdentific 

ationlChoice 

Identifikacija klirinškog 
sistema 

1.13 

М 1 

+ 

+ 

+ 

+ ClearingSystemIdentificat 
ion 

CashClearingSystem3 

Code 

Vrednost: KIB 

1.15 

М 1 

+ 

+ 

PaymentTypeInformation 

PaymentTypeInformat 

ion 

Informacije o tipu platnog 
servisa 

1.17 

М 1 

+ 

+ 

+ 

ServiceLevel 

ServiceLevelldentifica 

tion 

Identifikacija platnog 

servisa 

1.18 

М 1 

+ 

+ 

+ 

+ | ServiceCode 

ServiceLevelC ode 

Vrednost: SEPA 

1.26 

М 1 

+ 

+ 

InstructingAgent 

FinancialInstitution2 

Pošiljalac poruke 

1.26 

М 1 

+ 

+ 

+ 

Agentld 

F inanciallnstitutionlden 
tification4 

Identifikacija pošiljaoca 
poruke 

1.26 

М 1 

+ 

+ 

+ 

+ | BICAgent 

BlCIdentifier 

BIC pošiljaoca poruke 

1.27 

М 1 

+ 

+ 

InstructedAgent 

FinancialInstitution2 

Primalac poruke 

1.27 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitutionlden 

tification4 

Identifikacija primaoca 
poruke 

1.27 

М 1 

+ 

+ 

+ 

+ | BICAgent 

BlCIdentifier 

BIC primaoca poruke 

2.0 

М 1-n 

+ 

Transactionlnformation 

DirectDebitTransactio 

nInformation5 

Telo poruke instrukcije 
zaduženja 

2.1 

М 1 

+ 

+ 

Paymentld 

PaymentIdentificatio 

n2 

Identiiikatori plaćanja 

2.1 

М 1 

+ 

+ 

+ 

EndToEndld 

Max35Text 

Poziv na broj Poverioca 
ili ,,NONPROVIDED“. 

2.1 

М 1 

+ 

+ 

+ 

Transactionld 

Max35Text 

Jedinstveni Id transakcije 
podnosioca instrukcije. 

2.2 

М 1 

+ 

+ 

PaymentType 

PaymentTypeInformati 

on8 

Tip plaćanja 
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2.11 

M 1 

+ 

+ 

+ 

SequenceType 

SequenceType 1 Code 

Vrednosti: 

FRST,RECR,FLNL,ONEO 

2.12 

M 1 

+ 

+ 

+ 

CategoryPurpose 

CategoryPurposeCode 

Vrednosti: 

02 - za ovlašćenje 

definisana od strane 

banaka na nivou UBS 

03 - za ostala ugovoma 
ovlašćenja 

2.13 

M 1 

+ 

+ 

SettlementAmount 

EuroMaxl5Amount 

lznos transakcije 

2.13 

М 1 

+ 

+ 

+ 

Amount 

Decimal, 15,2 

Iznos transakcije u 

domaćoj valuti 

2.13 

М 1 

+ 

+ 

+ 

CurrencyCode 

EuroCurrencyC ode 

Kod domaće valute: RSD 

2.15 

0 0-1 

+ 

+ 

InstructedAmount 

CurrencyAndAmount 

Iznos transakcije, 

ugovorena valuta 

2.15 

0 0-1 

+ 

+ 

+ 

Amount 

Decimal, 9,2 

Ugovoreni iznos zaduženja 

2.15 

0 0-1 

+ 

+ 

+ 

CurrencyCode 

CurrencyCode 

Kod ugovorene valute 

2.16 

0 0-1 

+ 

+ 

ExchangeRate 

BaseOneRate 

Kurs ugovorene valute 

2.17 

М 1 

+ 

+ 

ChargeBearerCode 

ChargeBearerType2C 

ode 

Vrednost: SLEV 

2.19 

М 1 

+ 

+ 

RequestedDate 

ISODate 

Datum dospeća 

(DueDate) 

2.20 

М 1 

+ 

+ 

DirectDebitTransaction 

DirectDebitTransacti 

on4 

Informacija o direktnom 
zaduženju 

2.21 

М 1 

+ 

+ 

+ 

Mandatelnformation 

MandateRelatedlnfonna 

tion4 

Informacije o mandatu 

2.22 

М 1 

+ 

+ 

+ 

+ 

Mandateld 

Max35Text 

Identifikacija mandata ili 
aneksa 

2.23 

М 1 

+ 

+ 

+ 

+ 

DateSignature 

ISODate 

Datum potpisivanja 

mandata/aneks 

2.24 

М 1 

+ 

+ 

+ 

+ 

Amendmentlndicator 

TmeFalselndicator 

Indikator aneksa: TRUE, 
FALSE 

2.25 

0 0-1 

+ 

+ 

+ 

+ 

Amendmentlnformation 

Amendmentlnformatio 

nDetails4 

Informacije o osnovnom 
mandatu 

2.26 

0 0-1 

+ 

+ 

+ 

+ 

+ OriginalMandatld 

Max35Text 

Identifikator osnovnog 
mandata 

2.40 

М 1 

+ 

+ 

+ 

C reditorldlnformation 

C reditorldentificationln 
formation 

Informacija o identifikacij 
creditora 

2.40 

М 1 

+ 

+ 

+ 

+ 

Creditorld 

Max35Text 

Id Poverioca, matični broj 
ili Jmbg 

2.43 

М 1 

+ 

+ 

Creditor 

PartyIdentiflcationl3 

Poverilac 

2.43 

М 1 

+ 

+ 

+ 

Name 

Max70Text 

Ime poverioca 

2.43 

0 0-1 

+ 

+ 

+ 

PostAddress 

PostalAddress4 

Poštanska adresa 

poverioca 

2.43 

0 0-2 

+ 

+ 

+ 

+ 

Address 

Max70Text 

Adresa poverioca 

2.43 

М 1 

+ 

+ 

+ 

+ 

CountryCode 

CountryCode 

Kod države poverioca 

2.44 

М 1 

+ 

+ 

CreditorAccount 

CashAccount8 

Broj računa poverioca 

2.44 

М 1 

+ 

+ 

+ 

Accountld 

Accountldentification 

2 

Identifikacija računa 

poverioca 

2.44 

М 1 

+ 

+ 

+ 

+ 

IBANAccount 

IBANIdentifier 

IBAN broj računa 

poverioca 

2.45 

М 1 

+ 

+ 

CreditorAgent 

F inancialInstitution2 

Banka poverioca 

2.45 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitutionlden 

tification4 

Identifikacija banke 

poverioca 

2.43 

М 1 

+ 

+ 

+ 

+ | BICAgent 

BIC Identifier 

BIC banke poverioca 

2.47 

0 0-1 

+ 

+ 

UltimateCreditor 

Institution2 

Pravni subjekt 

2.47 

0 0-1 

+ 

+ 

+ 

Identification 

Institutionldentificatio 

n 

Identifikacija pravnog 

subjekta 

2.47 

0 0-1 

+ 

+ 

+ 

+ 

Organisationld 

PIBIdentifier 

PIB poverioca, Obavezno 
za pravne subjekte, Za 
preduzetnike JMBG 

2.57 

М 1 

+ 

+ 

Debtor 

PartyIdentiflcationl9 

Dužnika 

2.57 

М 1 

+ 

+ 

+ 

Debtorld 

Max35Text 

Id dužnika, matični broj ili 
Jmbg 

2.57 

М 1 

+ 

+ 

+ 

Name 

Max70Text 

Ime dužnika 

2.57 

0 0-1 

+ 

+ 

+ 

PostAddress 

PostalAddress4 

Poštanska adresa dužnika 
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2.57 

0 0-2 

+ 

+ 

+ 

+ 

Address 

Max70Text 

Adresa dužnika 

2.57 

M 1 

+ 

+ 

+ 

+ 

CountryCode 

CountryCode 

Kod države dužnika 

2.58 

M 1 

+ 

+ 

DebtorAccount 

CashAccount8 

Broj računa dužnika 

2.58 

M 1 

+ 

+ 

+ 

Accountld 

Accountldentification 

2 

Identifikacija računa 

dužnika 

2.58 

M 1 

+ 

+ 

+ 

+ 

IBANAccount 

IBANIdentifier 

IBAN broj računa 

dužnika 

2.59 

М 1 

+ 

+ 

DebtorAgent 

F inancialInstitution2 

Banka dužnika 

2.59 

М 1 

+ 

+ 

+ 

Agentld 

F inanciallnstitutionlden 
tification4 

Identifikacija banke 

dužnika 

2.59 

М 1 

+ 

+ 

+ 

+ | BICAgent 

BIC Identifier 

BIC banke dužnika 

2.61 

0 0-1 

+ 

+ 

UltimateDebtor 

Institution2 

Pravni subjekt 

2.61 

0 0-1 

+ 

+ 

+ 

Identification 

Institutionldentificatio 

n 

Identifikacija pravnog 

subjekta 

2.61 

0 0-1 

+ 

+ 

+ 

+ 

Organisationld 

PIBIdentifier 

PIB dužnika 

Obavezno za pravne 

subjekte 

Za preduzetnike JMBG 

2.62 

М 1 

+ 

+ 

Purpose 

PurposelChoice 

Informacija o svrsi 

plaćanja 

2.62 

М 1 

+ 

+ 

+ 

Purport 

Max35Text 

Svrhe plaćanja sa šifrom 
plaćanja : 

ХХХ -svrha plaćanja 

2.81 

0 0-1 

+ 

+ 

Remmitancelnformation 

Remittancelnformati 

опЗ 

Informacije o plaćanju 

2.82 

0 0-1 

+ 

+ 

+ 

UnstructuredRemmitance 

Maxl40Text 

Nestruktuirane informacije 
o plaćanju 

2.83 

0 0-1 

+ 

+ 

+ 

StructuredRemmitance 

StructuredRemittanceln 

formationć 

Struktuirane informacije o 
plaćanju 

2.84 

0 0-1 

+ 

+ 

+ 

+ 

ReferredDocument 

ReferredDocumentlnf 

ormationl 

Dokumentovanje plaćanja 

2.84 

0 0-1 

+ 

+ 

+ 

+ 

+ 

DocumentType 

ReferredDocumentTy 

pel 

Dokument 

2.84 

0 0-1 

+ 

+ 

+ 

+ 

+ 

+ | Purport 

Max35Text 

Naziv dokumenta 

2.97 

0 0-1 

+ 

+ 

+ 

+ 

CreditorReference 

C reditorReferencelnfo 
nnationl 

Referisanje poverioca na 
identifikator dužnika 

2.97 

0 0-1 

+ 

+ 

+ 

+ 

+ 

ReferenceType 

CreditorReferenceTyp 

el 

Referenca 

2.97 

0 0-1 

+ 

+ 

+ 

+ 

+ 

+ | Purport 

Max35Text 

Poziv na broj dužnika 

2.105 

0 0-1 

+ 

+ 

+ 

+ 

AdditionalRemmitanc 

Maxl40Text 

Dodatne informacije o 
plaćanju 


POSLOVNA PRAVILA 


Index 

Element poruke 

Poslovna pravila 

1.1 

Messageld 

U sistemu je jedinstven na nivou pošiljaoca. 

U slučaju standardizacije identifikatora u domaćem platnom 
prometu, kontrolu vršiti prema usvojenom standardu 

1.2 

CreationDate 

Manji ili jednak od SettlementDate 

1.5 

NumberTransaction 

Veći od nule. 

Broj instrukcija u poruci, odnosno broj ponavljanja 

T ransactionlnformation 

1.7 

TotalAmount .Amount 

Suma iznosa transakcija, odnosno 

suma SettlementAmount iz svake instrukcija 

1.7 

TotalAmount. Сиггепсу Code 

Vrednost: RSD 

1.8 

SettlementDate 

Veći od tekućeg datuma, a manji od tekućeg datuma+16 dana 

1.10 

SettlementMethodCode 

Vrednost: CLRG 

1.13 

ClearingSystemIdentification 

Vrednost: KIB 

1.26 

InstructingAgent. BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

1.27 

InstructedAgent. BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

2.1 

Paymentld. EndToEndld 

Predstavlja ID Collection instrukcije koji generiše Poverilac i 
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preko koga Poverilac identifikuje transakciju. Ukoliko 
Poverilac ne podnese ovaj ID svojoj banci, vrednost je 
,,NONPROVIDED“. 

Strukturapoziva na broj poverioca u domaćem platnom 
prometu: 

MMPPPPPPPPPPPPPPPPPPPP, gde je: 

MM - model poziva na broj sa vrednošću 97 ili „ „ 
PPPPPPPPPPPPPPPPPPPP - poziv na broj poverioca. 

Kontrola strukture ili vrednosti ,,NONPROVIDED“. 

2.1 

Paymentld. Transactionld 

Predstavlja ID Collection instrukcije koji generiše banka 
Poverioca i preko koga banka Poverioca identifikuje 
transakciju. 

Maksimalna dužina: Max32Text., osim u slučaju greške 
kada je Max35Text. 

U slučaju odbijanja instrukcije od strane Procesora zbog 
ustanovljene greške (Reject procesora), drugom učesniku se 
dostavlja linstrukcije u kojoj Transactionld započinje sa 
ERR+originalni Transactionld 

2.11 

PaymentType.SequenceType 

Vrednosti: FRST, RECR, FINL, ONEO 

FRST - prvo plaćanje po višestrukom mandatu 

RECR - ostala plaćanja po višestrukom mandatu osim prvog i 
poslednjeg 

FINL - poslednje plaćanje po višestrukom mandatu 

ONEO - plaćanje po jednostukom mandatu 

2.12 

PaymentT уре. Category Purpo 
se 

Vrednosti: 02, 03 

02 - za ovlašćenja kao osnov naplate koja su u posedu banke 
dužnika (poseban tip mandata defmisan na od strane banaka na 
nivou UBS,) 

03 - za ostala ugovorna ovlašćenja kao osnov naplate (opšti tip 
mandata) 

2.13 

SettlementAmount. Amount 

Veći od nule 

2.13 

SettlementAmount. 

CurrencyCode 

Vrednost: RSD 

2.15 

InstructedAmount. Amount 

Veći od nule. 

Moguća eventualna kontrola (po zahtevu) preračuna u domaću 
valutu: 

InstructedAmount* ExchangeRate= 

SettlementAmount.Amount 

2.15 

InstructedAmount. 

CurrencyCode 

Moguća eventualna kontrola (po zahtevu) da je kod valute iz 
šifarnika dozvoljenih valuta 

2.16 

ExchangeRate 

Veći od nule 

2.17 

ChargeB earerCode 

Vrednost: SLEV 

2.19 

RequestedDate 

Manji ilijednak SettlementDate. Uobičajeno, jednak datumu 
međubankarskog obračuna (SettlementDate), ali može biti i 
manji od njega u slučaju da je mandatom dozvoljena naplata 
u periodu od više dana od datuma dospeća 

2.22 

Mandateld 

Jedinstveni identifikator mandata ili aneksa koji generiše 
Poverilac i obezbeđuje njegovu jedinstvenost (na nivou 
Poverioca). 

Struktura mandata ID: 

a) Identiflkacija mandata ili aneksa-Identiflkacija 
pravnog lica koje je izdalo identifikaciju mandata ili 
aneksa i garantuje njegovu jedinstvenost na nvou 
Poverioca, ili 

b) Identiflkacija mandata ili aneksa (bez crtice) 

2.23 

DateSignature 

Manji od datuma dospeća (RequestedDate) 

2.24 

Amendmentlndicator 

TRUE - ukoliko se instrukcija podnosti po osnovu aneksa 
mandata 

FALSE - ukoliko se instrukcija podnosi po osnovu mandata 

2.25 

Amendmentlnformation 

Ukoliko je Amendmentlndicator =TRUE, odnosno ukoliko se 
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instrukcija podnosi po osnovu aneksa mandata, potrebno je 
dati i referencu (ID) osnovnog mandata . 

U slučaju standardizacije identifikatora u domaćem platnom 
prometu, kontrolu vršiti prema usvojenom standardu 

2.40 

Creditorld 

Struktura identifikatora u domaćem platnom prometu: 

Matični broj, dužine 8 - ukoliko se radi o Dužniku pravnom 
licu 

JMBG, dužine 13 - ukoliko se radi o Dužniku fizičkom licu 
koje obavlja delatnost 

Kontrola dužine . 

2.43 

Creditor. CountryCode 

Iz šifamika država 

2.44 

CreditorAccount. 

IBANAccount 

Struktura broja računa u domaćem platnom prometu: 

DDKKBBBnnnnnnnnnnnnnKB 

Gde je: 

DD - oznaka države (fiksna vrednost RS za Srbiju) 

KK - kontrolni broj po modelu 97 za ceo IBAN račun 
(fiksna vrednost 35 za Srbiju) 

BBB - šifra banke koja odgovara BIC-u banke poveriocž 

(CreditorAgent) 

nnnnnnnnnnnnn - broj računa 

KB - kontrolni broj za broj računa bez oznake države (DD) i 
kontrolnog broja (KK) 

2.45 

CreditorAgent. BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

2.47 

UltimateCreditor.Identificatio 
n .Organisationld 

PIB pravnog subjekta poverioca 

Kontrola: Dužina 9 (za pravna lica) ili 13 (za preduzetnike) 
znakova 

2.57 

Debtorld 

Struktura identifikatora u domaćem platnom prometu: 

Matični broj, dužine 8 - ukoliko se radi o Dužniku pravnom 
licu 

JMBG, dužine 13 - ukoliko se radi o Dužniku fizičkom licu 
koje obavlja delatnost 

Kontrola dužine . 

2.57 

Debtor. CountryCode 

Iz šifamika država 

2.58 

DebtorAccount. 

IBANAccount 

Struktura broja računa u domaćem platnom prometu: 

DDKKBBBnnnnnnnnnnnnnKB 

Gde je: 

DD - oznaka države (fiksna vrednost RS za Srbiju) 

KK - kontrolni broj po modelu 97 za ceo IBAN račun 
(fiksna vrednost 35 za Srbiju) 

BBB - šifra banke koja odgovara BIC-u banke dužnikž 
(DebtorAgent) 

nnnnnnnnnnnnn - broj računa 

KB - kontrolni broj za broj računa bez oznake države (DD) i 
kontrolnog broja (KK) 

2.59 

DebtorAgent. BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

2.61 

UltimateDebtor.ldentification 

.Organisationld 

PIB pravnog subjekta dužnika 

Kontrola: dužina 9 (za pravna lica) ili 13 (za preduzetnike) 
znakova 

2.62 

Purpose. Purport 

Strukturasvrhe plaćanja sa šifrom plaćanja u domaćem 
platnom prometu: 

ХХХ -svrha plaćanja, gde j e: 

XXX - Sifra plaćanja je opredeljena šifarnikom NBS 

Svrha plaćanja - predstavlja tekstualni opis svrhe plaćanja 
Kontrola strukture i (po zahtevu) šifre plaćanja iz propisanog 
šifarnika plaćanja 

2.82 

U nstructuredRemmitance 

Predstavlja tekstualni opis informacija o plaćanju koji 
obuhvata potvrdu ispunjenosti uslova za realizaciju plaćanja 
navedenih u mandatu. 
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2.84 

ReferredDocument. Purport 

Naziv dokumenta kojim se dokumentuje ispunjenost uslova 
za realizaciju plaćanja navedenih u mandatu 

2.97 

CreditorReference. Purport 

Referisanje Poverioca na identifikaciju Dužnika 

Predstavlja ID Collection instrukcije koji generiše Dužnik i 
preko koga Dužnik identifikuje transakciju. Strukturapoziva 
na brojdužnika u domaćem platnom prometu: 
MMPPPPPPPPPPPPPPPPPPPP, gde je: 

MM - model poziva na broj sa vrednošću 97 ili „ „ 
PPPPPPPPPPPPPPPPPPPP - poziv na broj dužnika. 

Kontrola strukture ili vrednosti ,,N0NPR0V1DED“. 

2.105 

AdditionalRemmitance 

Druge struktuirane informacije dogovorene od strane 
Dužnika i Poverioca koje služe za dokumentovanje 
ispunjenosti uslova za realizaciju plaćanja navedenih u 
mandatu 


PORUKA pacs.004.001.01 RETURN/REFUND 
Struktura: SerbianReturn 

• Koristi se za iniciranje i izvršenje storniranja realizovane transakcija direktnog zaduženja kojim se 
vrši povraćaj sredstava 

• Generiše je banka dužnika i ispostavlja procesoru ili procesor 

• Poruka se sastoji od zaglavlja (Group Header) koje nosi zajedničke informacije svih transakcija za 
storniranje realizovanih direktnog zaduženja iz poruke i tela poruke (Transaction Information) koje 
nosi informacije o pojedinačnim transakcijama za storniranje realizovanih direktnih zaduženja koje 
banka inicira. 


• Struktura poruke: 


Index 

Kardin 

alnost 

Element poruke 

Tip 

Opis i poslovna 
pravila 

1.0 

M 1 

+ 

Header 

GroupHeader21 

Zaglavlje poruke 

1.1 

M 1 

+ 

+ 

Messageld 

Max35Text 

Jedinstveni 
identifikator 
poruke koji formira 
pošiljalac poruke 

1.2 

M 1 

+ 

+ 

CreationDate 

ISODateTime 

Datum kreiranja 

poruke 

1.5 

M 1 

+ 

+ 

N umberT ransaction 

Мах 15N umericT ext 

Ukupan broj 

transakcija u poruci 

1.8 

М 1 

+ 

+ 

TotalAmount 

EuroMaxl 5Amount 

Ukupan iznos 

transakcija u poruci 

1.8 

М 1 

+ 

+ 

+ 

Amount 

Decimal, 15,2 

Ukupan iznos 

transakcija u poruci 

1.8 

М 1 

+ 

+ 

+ 

Сиггепсу Code 

EuroC иггепсу Code 

Kod domaće valute: 
RSD 

1.9 

М 1 

+ 

+ 

SettlementDate 

ISODate 

Datum 

međubankarskog 

obračuna 

1.10 

М 1 

+ 

+ 

Settlementlnformation 

Settlementlnformatio 

nll 

Informacije o 

obračunu 

1.11 

М 1 

+ 

+ 

+ 

SettlementMethodCode 

SettlementMethod2C 

ode 

Vrednost: CLRG 

1.12 

М 1 

+ 

+ 

+ 

ClearingSystem 

ClearingSystemldentifi 

cationlChoice 

Identifikacija 
klirinškog sistema 

1.13 

М 1 

+ 

+ 

+ 

+ 

ClearingSystemIdentific 

ation 

CashClearingSystem 

3Code 

Vrednost: KIB 

1.22 

М 1 

+ 

+ 

InstructingAgent 

Financiallnstitution 

2 

Pošiljalac poruke 

1.22 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitutionlde 

ntification4 

Identifikacija 
pošiljaoca poruke 

1.22 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC pošiljaoca 

poruke 
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1.23 

M 1 

+ 

+ 

InstructedAgent 

Financiallnstitution 

2 

Primalac poruke 

1.23 

M 1 

+ 

+ 

+ 

Agentld 

Financiallnstitutionlde 

ntification4 

Identifikacija 
primaoca poruke 

1.23 

M 1 

+ 

+ 

+ 

+ BICAgent 

BlCldentifier 

BIC primaoca 

poruke 

3.0 

M 1-n 

+ 

Т ra nsactionlnfor mation 

PaymentTransactionInf 

ormationl3 

Telo poruke za 
Return/Refund 

3.1 

М 1 

+ 

+ 

Transactionld 

Max35Text 

Jedinstveni Id 

transakcije 
podnosioca 
instrukcije 

3.2 

М 1 

+ 

+ 

OriginalTransactionlnformatio 

n 

OriginalGroupInform 

ation8 

Identifikacija 
originalne poruke 

3.3 

М 1 

+ 

+ 

+ 

OriginalMessageld 

Max35Text 

Jedinstveni 
identifikator 
originalne poruke 

3.4 

М 1 

+ 

+ 

+ 

OriginalMessageName 

Max35Text 

Naziv originalne 
instrukcije. 

Vrednost: 

pacs.003.001.01 

3.5 

0 0-1 

+ 

+ 

+ 

OriginalCreationDate 

ISODateTime 

Datum kreiranja 

originalne poruke 

3.7 

М 1 

+ 

+ 

OriginalEndT oEndld 

Max35Text 

Poziv na broj 

Poverioca iz 

originalne 
instrukcije 

3.8 

М 1 

+ 

+ 

OriginalT ransactionld 

Max35Text 

Id transakcije banke 
Poverioca iz 

originalne 
instrukcije 

3.9 

М 1 

+ 

+ 

OriginalSettlementAmount 

EuroMaxl 5Amount 

Iznos transakcije iz 

originalne 

instrukcije. 

3.9 

М 1 

+ 

+ 

+ 

Amount 

Decimal, 15,2 

Iznos transakcije u 
domaćoj valuti iz 
originalne 
instrukcije 

3.9 

М 1 

+ 

+ 

+ 

CurrencyCode 

EuroC иггепсу Code 

Kod domaće valute 
iz originalne 

instrukcije: RSD 

3.10 

М 1 

+ 

+ 

ReturnedSettlementAmount 

EuroMaxl 5Amount 

Iznos sredstava za 
povraćaj 
transakcijom 
Return/Refund 

3.10 

М 1 

+ 

+ 

+ 

Amount 

Decimal, 15,2 

Iznos za povraćaj u 
domaćoj valuti 

3.10 

М 1 

+ 

+ 

+ 

CurrencyCode 

EuroCurrencyCode 

Kod domaće valute: 
RSD 

3.19 

М 1-n 

+ 

+ 

ReturnReasonlnformation 

ReturnReasonlnfor 

mation4 

Informacije o 

raziozima 

povraćaja 

3.20 

М 1 

+ 

+ 

+ 

ReturnOriginator 

Partyldentification 14 

Identifikacija 
podnosioca 
instrukcije za 

povraćaj: 

BIC banke za Return 
Naziv dužnika za 
Refund 
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3.20 

{or 

+ 

+ 

+ 

+ 

Originatorld 

PartyOrganisation 1C 
hoice 

Identifikacija 
banke podnosioca 
Return instrukciju 

3.20 

M 1 

+ 

+ 

+ 

+ 

+ 

Originator 

Organisationldentificat 

ion3 

Identifikacija 
banke podnosioca 

3.20 

M 1 

+ 

+ 

+ 

+ 

+ 

+ BlCOriginator 

BlCldentifier 

BIC banke 

podnosioca 

3.20 

or} 

+ 

+ 

+ 

+ 

OriginatorName 

Max35Text 

Naziv Dužnika koji 
inicira povraćaj sa 
Refund instrukcijom 

3.21 

M 1 

+ 

+ 

+ 

ReturnReason 

ReturnReason3 Choic 

e 

Kodirani razlog za 
povraćaj 

3.22 

M 1 

+ 

+ 

+ 

+ 

ReasonCode 

TransactionReturnRea 

son5Code 

Kod razloga za 
povraćaj 

3.24 

0 0-n 

+ 

+ 

+ 

AdditionalReasonlnformatio 

n 

Maxl05Text 

Dodatno 

obrazloženje za 

povraćaj 

3.25 

M 1 

+ 

+ 

OriginalT ransactionReferenc 
е 

OriginalTransaction 

Reference7 

Podaci iz originalne 
instrukcije 

3.32 

M 1 

+ 

+ 

+ 

SettlementDate 

ISODate 

Datum 

međubankarskog 

obračuna 

originalne 

transakcije 

3.34 

М 1 

+ 

+ 

+ 

RequestedDate 

ISODate 

Datum dospeća 

(DueDate) iz 

originalne 
transakcije 

3.35 

М 1 

+ 

+ 

+ 

Creditorldlnformation 

Creditorldentificationl 

nformation 

Informacija c 

identifikaciji 
Poverioca h 

originalne instrukcije 

3.35 

М 1 

+ 

+ 

+ 

+ 

Creditorld 

Max35Text 

Id Poverioca, 

matični broj ili Jmbg 
iz originalne 

instrukcije. 

3.48 

М 1 

+ 

+ 

+ 

PaymentType 

PaymentT ypelnformati 
on9 

Tip plaćanja iz 

originalne 

instrukcije 

3.48 

М 1 

+ 

+ 

+ 

+ 

SequenceType 

SequenceT уре 1 Code 

Kod tipa plaćanja iz 

originalne 

instrukcije 

3.49 

М 1 

+ 

+ 

+ 

+ 

CategoryPurpose 

CategoryPui*poseCod 

e 

Vrednosti: 

02 - za ovlašćenje 
defmisana od strane 
banaka na nivou 
UBS 

03 - za ostala 
ugovorna ovlašćenja 

3.60 

М 1 

+ 

+ 

+ 

Mandatelnformation 

MandateRelatedlnform 

ation4 

Informacije o 

mandatu ili aneksu 
iz originalne 

instrukcije 

3.60 

М 1 

+ 

+ 

+ 

+ 

Mandateld 

Max35Text 

Identifikacija 
mandata ili aneksa iz 
originalne 
instrukcije 

3.60 

М 1 

+ 

+ 

+ 

+ 

DateSignature 

ISODate 

Datum potpisivanja 
mandata ili aneksa 
iz originalne 
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instrukcije 

3.60 

M 1 

+ 

+ 

+ 

+ 

Amendmentlndicator 

TrueFalselndicator 

Indikator aneksa iz 

originalne 

instrukcije 

3.60 

0 0-1 

+ 

+ 

+ 

+ 

Amendmentlnformation 

Amendmentlnformati 

onDetails4 

Informacije o 

osnovnom mandatu 
iz originalne 

instrukcije 

3.60 

0 0-1 

+ 

+ 

+ 

+ 

+ 

OriginalMandateld 

Max35Text 

Identifikator 
osnovnog mandata 
iz originalne 

instrukcije 

3.79 

0 0-1 

+ 

+ 

+ 

Remmitancelnformation 

Remittanc elnformati 
опЗ 

Informacije o 

plaćanju 

Remmitanc elnform 
ation iz originalne 
Collection 
instrukcije 

(svi atributi iz 

originalne 

instrukcija). 

3.79 

0 0-1 

+ 

+ 

+ 

+ 

UnstructuredRemmitanc 

e 

Maxl40Text 

Nestruktuirane 
informacije o 

plaćanju 

3.79 

0 0-1 

+ 

+ 

+ 

+ 

StructuredRemmitance 

StructuredRemittancel 

nformationć 

Struktuirane 
informacije o 

plaćanju 

3.79 

0 0-1 

+ 

+ 

+ 

+ 

+ 

ReferredDocument 

ReferredDocumentln 

formationl 

Dokumentovanje 

plaćanja 

3.79 

0 0-1 

+ 

+ 

+ 

+ 

+ 

+ 

DocumentType 

ReferredDocumentTy 

pel 

Dokument 

3.79 

0 0-1 

+ 

+ 

+ 

+ 

+ 

+ 

+ 

Purport 

Max35Text 

Naziv dokumenta 

3.79 

0 0-1 

+ 

+ 

+ 

+ 

+ 

CreditorReference 

Creditor Reference 
Informationl 

Referisanje 
poverioca na 

identifikator dužnika 

3.79 

0 0-1 

+ 

+ 

+ 

+ 

+ 

+ 

ReferenceType 

CreditorReferenceT у 
pel 

Referenca 

3.79 

0 0-1 

+ 

+ 

+ 

+ 

+ 

+ 

+ 

Purport 

Max35Text 

Poziv na broj 
dužnika 

3.79 

0 0-1 

+ 

+ 

+ 

+ 

+ 

AdditionalRemmitan 

ce 

Maxl40Text 

Dodatne informacije 
o plaćanju 

3.105 

M 1 

+ 

+ 

+ 

Debtor 

PartyIdentification 19 

Dužnika iz 

originalne 
instrukcije 
(svi atributi iz 

originalne 
instrukcija) 

3.105 

M 1 

+ 

+ 

+ 

+ 

Debtorld 

Max35Text 

ID dužnika, matični 
broj ili Jmbg iz 
originalne 
instrukcije 

3.105 

M 1 

+ 

+ 

+ 

+ 

Name 

Max70Text 

Naziv dužnika iz 

originalne 

instrukcije 

3.105 

0 0-1 

+ 

+ 

+ 

+ 

PostAddress 

PostalAddress4 

Poštanska adresa 
dužnika iz 

originalne 
instrukcije 

3.105 

0 0-2 

+ 

+ 

+ 

+ 

+ 

Address 

Max70Text 

Adresa dužnika iz 
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originalne 

instrukcije 

3.105 

M 1 

+ 

+ 

+ 

+ 

+ 

CountryCode 

CountryCode 

Kod države dužnika 
iz originalne 

instrukcije 

3.106 

M 1 

+ 

+ 

+ 

DebtorAccount 

CashAccount8 

Broj računa 

dužnika iz 

originalne 
instrukcije 

3.106 

M 1 

+ 

+ 

+ 

+ 

Accountld 

Accountldentification 

2 

Identifikacija 
računa dužnika iz 
originalne 
instrukcije 

3.106 

M 1 

+ 

+ 

+ 

+ 

+ 

IBANAccount 

IBANldentifier 

IBAN broj računa 
dužnika iz 

originalne 
instrukcije 

3.107 

М 1 

+ 

+ 

+ 

DebtorAgent 

FinancialInstitution2 

Banka dužnika iz 

originalne 

instrukcije 

3.107 

М 1 

+ 

+ 

+ 

+ 

Agentld 

Financiallnstitutionlde 

ntification4 

Identifikacija banke 
dužnika iz originalne 
instrukcije 

3.107 

М 1 

+ 

+ 

+ 

+ 

+ 

BICAgent 

BIC Identifier 

BIC banke dužnika 
iz originalne 

instrukcije 

3.108 

0 0-1 

+ 

+ 

+ 

UltimateDebtor 

Institution2 

Pravni subjekt 

3.108 

0 0-1 

+ 

+ 

+ 

+ 

Identification 

Institutionldentificati 

on 

Identifikacija 
pravnog subjekta 

3.108 

0 0-1 

+ 

+ 

+ 

+ 

+ 

Organisationld 

PIBIdentifier 

PIB dužnika 
Obavezno za pravne 
subjekte 

Za preduzetnike 

JMBG 

3.111 

М 1 

+ 

+ 

+ 

Creditor 

Partyldentificationl 3 

Poverilac iz 

originalne 

instrukcije 

(svi atributi iz 

originalne 

instrukcija) 

3.111 

М 1 

+ 

+ 

+ 

+ 

Name 

Max70Text 

Ime poverioca iz 

originalne 

instrukcije 

3.111 

0 0-1 

+ 

+ 

+ 

+ 

PostAddress 

PostalAddress4 

Poštanska adresa 
poverioca iz 

originalne 
instrukcije 

3.111 

0 0-2 

+ 

+ 

+ 

+ 

+ 

Address 

Max70Text 

Adresa poverioca iz 

originalne 

instrukcije 

3.111 

М 1 

+ 

+ 

+ 

+ 

+ 

CountryCode 

CountryCode 

Kod države 

poverioca iz 

originalne 
instrukcije 

3.112 

М 1 

+ 

+ 

+ 

CreditorAccount 

CashAccount8 

Broj računa 

poverioca iz 

originalne 
instrukcije 

3.112 

М 1 

+ 

+ 

+ 

+ 

Accountld 

Accountldentification 

2 

Identifikacija 
računa poverioca iz 
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originalne 

instrukcije 

3.112 

M 1 

+ 

+ 

+ 

+ 

+ 

IBANAccount 

IBANIdentifier 

IBAN broj računa 
poverioca iz 

originalne 
instrukcije 

3.109 

M 1 

+ 

+ 

+ 

CreditorAgent 

FinancialInstitution2 

Banka poverioca iz 

originalne 

instrukcije 

3.109 

M 1 

+ 

+ 

+ 

+ 

Agentld 

Financiallnstitutionlde 

ntification4 

Identifikacija banke 
poverioca iz 

originalne 
instrukcije 

3.109 

M 1 

+ 

+ 

+ 

+ 

+ 

BICAgent 

BIC Identifier 

BIC banke poverioca 
iz originalne 

instrukcije 

3.113 

0 0-1 

+ 

+ 

+ 

UltimateCreditor 

Institution2 

Pravni subjekt 

3.113 

0 0-1 

+ 

+ 

+ 

+ 

Identification 

Institutionldentificati 

on 

Identifikacija 
pravnog subjekta 

3.113 

OO-l 

+ 

+ 

+ 

+ 

+ 

Organisationld 

PIBldentifier 

PIB poverioca 
Obavezno za pravne 
subjekte 

Za preduzetnike 

JMBG 


Spe cifikacija ISO kodova za Return/Refun d t ransakcije: 


ISO kod 

Opis 

ACOl 

Pogrešan broj računa 

AC04 

Račun zatvoren 

AC06 

Račun blokiran 

AGOl 

Transakcija zabranjena 

AG02 

Pogrešan kod banke 

AMOl 

Nula iznos 

AM02 

Nedopušten račun 

AM03 

Nedopuštena valuta 

AM04 

Nedovoljno sredstava 

AM05 

Dupliran nalog 

AM06 

Premali iznos 

AM07 

Blokiran iznos 

AM09 

Pogrešan iznos 

AMIO 

Pogrešna kontrolna suma 

BEOl 

Nesaglasan krajnji korisnik 

BE04 

Pogrešna adresa poverioca 

BE05 

Neprepoznat poverilac 

BE06 

Neprepoznat dužnik 


ISO kod 

Opis 

BE07 

Pogrešna adresa dužnika 

DTOl 

Pogrešan datum 

EDOl 

Ne postoji korespodentna banka 

ED03 

Traženo stanje 

MDOl 

Nema validnog mandata 

MD02 

Pogrešne informacije o mandatu 

MD03 

Pogrešan format podatka o razlozima 

MD04 

Pogrešan format podataka za indikatore 

MD06 

Dužnik je podneo Refunda zahtev 

MD07 

Dužnik je umro 

MS02 

Nije naveden razlog od strane dužnika 

MS03 

Nije naveden razlog od strane banke 

NARR 

Opisno 

RCOl 

Pogrešan identifikator banke 

RFOl 

Referenca transakcije nije jedinstvena 

TMOl 

Cutt off time (istek vremena) 

ED05 

Greška u obračunu 

RROl 

Razlozi regulatora (procesora) 


POSLOVNA PRAVILA 


Index 

Element poruke 

Poslovna pravila 

1.1 

Messageld 

U sistemu je jedinstven na nivou pošiljaoca. 

U slučaju standardizacije identifikatora u domaćem platnom 
prometu, kontrolu vršiti prema usvojenom standardu 

1.2 

CreationDate 

Manji ili jednak od SettlementDate 

1.5 

NumberTransaction 

Veći od nule. 

Broj instrukcija u poruci, odnosno broj ponavljanja 
Transactionlnformation 

1.8 

TotalAmount .Amount 

Suma iznosa transakcija, odnosno 

suma RetrnedSettlementAmount iz svake instrukcija 
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1.8 

TotalAmount. Сиггепсу Code 

Vrednost: RSD 

1.9 

SettlementDate 

Veći od tekućeg datuma, a manji od tekućeg datuma+16 
dana 

1.11 

SettlementMethodCode 

Vrednost: CLRG 

1.13 

ClearingSystemIdentification 

Vrednost: KIB 

1.22 

InstructingAgent. BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

1.23 

InstructedAgent. BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

3.1 

Transactionld 

Predstavlja ID Return/Refund instrukcije koji generiše banka 
Dužnika i preko koga banka Dužnika identifikuje transakciju 
Maksimalna dužina: Max32Text., osim u slučaju greške 
kada je Max35Text. 

U slučaju odbijanja instrukcije od strane Procesora zbog 
ustanovljene greške (Reject procesora), drugom učesniku se 
dostavlja instrukcije u kojoj Transactionld započinje sa 
ERR+originalni Transactionld 

3.3 

OriginalMessageld 

Messageld iz Header-a poruke u kojoj se nalazila originalna 
Collection instrukcija. 

Predstavlja jedinstveni identifikator poruke u kojoj se 
nalazila originalna Collection instrukcija. 

Kontrola postojanja poruke u evidenciji procesora 

3.4 

OriginalMessageName 

Vrednost: pacs.003.001.01 

3.5 

OriginalCreationDate 

CreationDate iz Header-a poruke u kojoj se nalazila 
originalna Collection instrukcija 

3.7 

OriginalEndT oEndld 

EndToEndlD iz originalne Collection instrukcije. 

Predstavlja ID originalne Collection instrukcije koji je 
generisao Poverilac. 

3.8 

OriginalT ransactionld 

TransactionlD iz originalne Collection instrukcije. 

Predstavlja ID originalne Collection instrukcije koji je 
generisala banka Poverioca 

Kontrola postojanja instrukcije u evidenciji procesora 

3.9 

Original Settlement Amo unt. 
Amount 

SettlementAmount iz originalne Collection instrukcije. 
Kontrola iznosa originalne transakcije koji je realizovan u 
kliringu, u evidenciji procesora 

3.9 

OriginalSettlementAmount. 

CurrencyCode 

Vrednost: RSD 

3.10 

ReturnedSettlementAmount. 

Amount 

Uobičajeno, jednak iznosu OriginalSettlementAmount 

Može biti i različit u slučaju da je to predviđeno i dozvoljeno 
mandatom 

3.10 

ReturnedSettlementAmount. 

CurrencyCode 

Vrednost: RSD 

3.20 

ReturnOriginator 


3.20 

ReturnOriginator. 

BlCOriginator 

Podnosilac instrukcije može biti Banka Dužnika, za Return 
instrukciju, koja se identifikuje svojim BlC-om i Dužnik, za 
Refund instrukcije, koji se identifikuje svojim nazivom. 

BIC banke dužnika mora biti u evidenciji aktivnih učesnika 
kliringa za direktna zaduženja 

3.22 

ReturnReason. ReasonCode 

Kontrola koda razloga povraćaja u šifarniku kodova 
povraćaja 

3.24 

AdditionalReasonlnformation 

Ukoliko šifrirani kod razloga povraćaja ne objašnjava 
dovoljno razloge za povraćaja, može se zadati i njegov 
tekstualni opis. 

3.32 

OriginalT ransactionReference 
. SettlementDate 

SettlementDate iz Header-a poruke u kojoj se nalazila 
originalna Collection instrukcija 

Kontrola SettlementDate iz originalne instrukcije, u 
evidenciji procesora 

3.34 

OriginalT ransactionReference 
. RequestedDate 

RequestedDate iz originalne Collection instrukcije 
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3.35 

Creditorldlnformation. 

Creditorld 

Creditorld iz originalne Collection instrukcije. 

3.48 

PaymentType. 

SequenceType 

SequenceType iz originalne Collection instrukcije: 

FRST - prvo plaćanje po višestrukom mandatu 

RECR - ostala plaćanja po višestrukom mandatu osim prvog i 
poslednjeg 

FINL - poslednje plaćanje po višestrukom mandatu 

ONEO - plaćanje po jednostukom mandatu 

3.49 

PaymentType.CategoryPurpo 

se 

Vrednosti: 02, 03 

02 - za ovlašćenja kao osnov naplate koja su u posedu banke 
dužnika (poseban tip mandata defmisan na od strane banaka 
na nivou UBS,) 

03 - za ostala ugovorna ovlašćenja kao osnov naplate (opšti 
tip mandata) 

3.60 

Mandatelnformation 

Mandateld 

Mandateld iz originalne Collection instrukcije 

3.60 

Mandatelnformation 

DateSignature 

DateSignature iz originalne Collection instrukcije 

3.60 

Mandatelnformation 

Amendmentlndicator 

Amendmentlndicator iz originalne Collection instrukcije 

3.60 

Mandatelnformation 

OriginalMandateld 

Amendmentlnformation iz originalne Collection instrukcije. 

ID osnovnog mandata ukoliko je Amendmentlndicator iz 
originalne Collection instrukcije=TRUE 

3.79 

Remmitancelnformation 

Remmitancelnformation iz originalne Collection instrukcije 

3.105 

Debtor 

Debtor iz originalne Collection instrukcije 

3.106 

DebtorAccount. 

IBANAccount 

Struktura broja računa u domaćem platnom prometu: 

DDKKBBBnnnnnnnnnnnnnKB 

Gde je: 

DD - oznaka države (fiksna vrednost RS za Srbiju) 

KK - kontrolni broj po modelu 97 za ceo IBAN račun 
(fiksna vrednost 35 za Srbiju) 

BBB - šifra banke koja odgovara BIC-u banke dužnika 
(DebtorAgent) 

nnnnnnnnnnnnn - broj računa 

KB - kontrolni broj za broj računa bez oznake države (DD) i 
kontrolnog broja (KK) 

3.107 

DebtorAgent. BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

3.108 

UltimateDebtor.ldentification 

.Organisationld 

PIB pravnog subjekta dužnika 

Kontrola: dužina 9 (za pravna lica) ili 13 (za preduzetnike) 
znakova 

3.111 

Creditor 

Creditor iz originalne Collection instrukcije (svi atributi iz 
originalne instrukcija) 

3.112 

CreditorAccount. 

IBANAccount 

Struktura broja računa u domaćem platnom prometu: 

DDKKBBBnnnnnnnnnnnnnKB 

Gde je: 

DD - oznaka države (fiksna vrednost RS za Srbiju) 

KK - kontrolni broj po modelu 97 za ceo IBAN račun 
(fiksna vrednost 35 za Srbiju) 

BBB - šifra banke koja odgovara BIC-u banke poveriocž 

(CreditorAgent) 

nnnnnnnnnnnnn - broj računa 

KB - kontrolni broj za broj računa bez oznake države (DD) i 
kontrolnog broja (KK) 

3.109 

CreditorAgent. BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

3.113 

UltimateCreditor.Identificatio 
n .Organisationld 

PIB pravnog subjekta poverioca 

Kontrola: dužina 9 (za pravna lica) ili 13 (za preduzetnike) 
znakova 
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PORUKA pacs.007.001.01 REVERSAL 
Struktura: SerbianReversal 

• Koristi se za povraćaj sredstava po realizovanoj transakciji direktnog zaduženja 

• Generiše je banka poverioca i ispostavlja procesoru 

• Poruka se sastoji od zaglavlja (Group Header) koje nosi zajedničke informacije svih transakcija 
direktnog zaduženja za povraćaj sredstava iz poruke i tela poruke (Transaction Information) koje nosi 
informacije o pojedinačnim transakcijama za povraćaj sredstava koje inicira banka. 

• Struktura poruke: 


Index 

Kardin 

alnost 

Element poruke 

Tip 

Opis i poslovna 
pravila 

1.0 

M 1 

+ 

Header 

GroupHeader22 

Zaglavlje poruke 

1.1 

M 1 

+ 

+ 

Messageld 

Max35Text 

Jedinstveni identifikator 
poruke koji formira 
pošiljalac poruke 

1.2 

M 1 

+ 

+ 

CreationDate 

ISODateTime 

Datum kreiranja poruke 

1.5 

M 1 

+ 

+ 

N umberT ransaction 

Мах 15NumericT ext 

Ukupan broj transakcija 
u poruci 

1.7 

М 1 

+ 

+ 

GroupReserval 

T rueFalselndicator 

Indikator grupnog 

vraćanja sa 

1.8 

М 1 

+ 

+ 

TotalAmount 

EuroMaxl 5Amount 

Ukupan iznos 

transakcija u poruci 

1.8 

М 1 

+ 

+ 

+ 

Amount 

Decimal, 15,2 

Ukupan iznos 

transakcija u poruci 

1.8 

М 1 

+ 

+ 

+ 

Сиггепсу Code 

EuroCurrencyCode 

Kod domaće valute: RSD 

1.9 

М 1 

+ 

+ 

SettlementDate 

ISODate 

Datum 

međubankarskog 

obračuna 

1.10 

М 1 

+ 

+ 

Settlementlnformation 

Settlementlnformati 

onll 

Informacije o obračunu 

1.11 

М 1 

+ 

+ 

+ 

SettlementMethodCode 

SettlementMethod2 

Code 

Vrednost: CLRG 

1.12 

М 1 

+ 

+ 

+ 

ClearingSystem 

ClearingSystemldenti 

ficationlChoice 

Identifikacija klirinškog 

sistema 

1.13 

М 1 

+ 

+ 

+ 

+ 

ClearingSystemldentific 

ation 

CashClearingSystem 

3Code 

Vrednost: KIB 

1.22 

М 1 

+ 

+ 

InstructingAgent 

Financiallnstitutio 

n2 

Pošiljalac poruke 

1.22 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitutionld 

entification4 

Identifikacija pošiljaoca 
poruke 

1.22 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC pošiljaoca poruke 

1.23 

М 1 

+ 

+ 

InstructedAgent 

Financiallnstitutio 

n2 

Primalac poruke 

1.23 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitutionld 

entification4 

Identifikacija primaoca 
poruke 

1.23 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC primaoca poruke 

3.0 

М 1-n 

+ 

Т ra nsactionlnfor mation 

PaymentTransactionIn 

formationl4 

Telo poruke za 

Reversal 

3.1 

М 1 

+ 

+ 

Transactionld 

Max35Text 

Jedinstveni Id 

transakcije podnosioca 
instrukcije 

3.4 

М 1 

+ 

+ 

OriginalEndT oEndld 

Max35Text 

Poziv na broj Poverioca 
iz originalne instrukcije 

3.5 

М 1 

+ 

+ 

OriginalT ransactionld 

Max35Text 

Id transakcije banke 
Poverioca iz originalne 
instrukcije 

3.6 

М 1 

+ 

+ 

OriginalSettlementAmount 

ЕигоМах! 5Amount 

Iznos transakcije iz 
originalne instrukcije. 


Slobodan Babić \ Fakultet organizacionih nauka 


356 










































Doktorska disertacija: Model interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama 


3.6 

M 1 

+ 

+ 

+ 

Amount 

Decimal, 15,2 

Iznos transakcije u 
domaćoj valuti iz 

originalne instrukcije 

3.6 

M 1 

+ 

+ 

+ 

CurrencyCode 

EuroC иггепсу Code 

Kod domaće valute iz 
originalne instrukcije: 

RSD 

3.7 

M 1 

+ 

+ 

ReversedSettlementAmount 

EuroMxl 5Amount 

Iznos sredstava za 
povraćaj transakcijom 
Reversal 

3.7 

M 1 

+ 

+ 

+ 

Amount 

Decimal, 15,2 

Iznos za povraćaj u 
domaćoj valuti 

3.7 

М 1 

+ 

+ 

+ 

CurrencyCode 

EuroCurrencyCode 

Kod domaće valute: RSD 

3.16 

М 1-n 

+ 

+ 

ReversalReasonlnformation 

ReversalReasonlnf 

ormation4 

Informacije o 

razlozima povraćaja 

3.17 

М 1 

+ 

+ 

+ 

ReversalOriginator 

PartyIdntification 14 

Identifikacija podnosioca 
instrukcije za povraćaj: 
BIC banke ili Id 
poverioca 

3.17 

{or 

+ 

+ 

+ 

+ 

Originatorld 

PartyOrganisation 1C 
hoice 

Identifikacija banke 

podnosioca Reversal 

instrukciju 

3.17 

М 1 

+ 

+ 

+ 

+ 

+ 

Originator 

Organisationldentifi 

cation3 

Identifikacija banke 

podnosioca 

3.17 

М 1 

+ 

+ 

+ 

+ 

+ 

+ BlCOriginator 

BlCldentifier 

BIC banke podnosioca 

3.17 

or} 

+ 

+ 

+ 

+ 

OriginatorName 

Max35Text 

Naziv Poverioca koji 
inicira povraćaj sa 

Reversal instrukcijom 

3.18 

М 1 

+ 

+ 

+ 

ReversalReason 

ReturnRson3Choice 

Kodirani razlog za 
povraćaj 

3.19 

М 1 

+ 

+ 

+ 

+ 

ReasonCode 

TransactionReturnRe 

ason2Code 

Kod razloga za povraćaj 

3.21 

0 0-1 

+ 

+ 

+ 

AdditionalReasonlnformatio 

n 

Maxl05Text 

Dodatno obrazloženje 
za povraćaj 

3.22 

М 1 

+ 

+ 

OriginalT ransactionReferenc 
e 

OriginalTransaction 

Reference7 

Podaci iz originalne 
instrukcije 

3.29 

М 1 

+ 

+ 

+ 

SettlementDate 

ISODate 

Datum 

međubankarskog 
obračuna originalne 

transakcije 

3.31 

М 1 

+ 

+ 

+ 

RequestedDate 

ISODate 

Datum dospeća 

(DueDate) iz originalne 
transakcije 

3.32 

М 1 

+ 

+ 

+ 

Creditorldlnformation 

Creditorldentification 

Information 

Informacija c 

identifikaciji Poverioca h 
originalsne instrukcije 

3.32 

М 1 

+ 

+ 

+ 

+ 

Creditorld 

Max35Text 

Id Poverioca, matični 
broj ili Jmbg iz 

originalne instrukcije. 

3.45 

М 1 

+ 

+ 

+ 

PaymentType 

PaymentTypelnforma 

tion9 

Tip plaćanja iz 

originalne instrukcije 

3.45 

М 1 

+ 

+ 

+ 

+ 

SequenceType 

SequnceT уре 1 Code 

Kod tipa plaćanja iz 
originalne instrukcije 

3.46 

М 1 

+ 

+ 

+ 

+ 

CategoryPurpose 

CategryPrposeCode 

Vrednosti: 

02 - za ovlašćenje 

defmisana od strane 
banaka na nivou UBS 

03 - za ostala ugovorna 
ovlašćenja 

3.57 

М 1 

+ 

+ 

+ 

Mandatelnformation 

MandateRelatedlnfor 

Informacije o mandatu 
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mation4 

ili aneksu iz originalne 
instrukcije 

3.57 

M 1 

+ 

+ 

+ 

+ 

Mandateld 

Max35Text 

Identifikacija mandata ili 
aneksa iz originalne 
instrukcije 

3.57 

M 1 

+ 

+ 

+ 

+ 

DateSignature 

ISODate 

Datum potpisivanja 

mandata ili aneksa iz 
originalne instrukcije 

3.57 

M 1 

+ 

+ 

+ 

+ 

Amendmentlndicator 

T rueFalselndicator 

Indikator aneksa iz 
originalne instrukcije 

3.57 

0 0-1 

+ 

+ 

+ 

+ 

Amendmentlnformation 

Amendmentlnformat 

ionDetails4 

Informacije o osnovnom 
mandatu iz originalne 
instrukcije 

3.57 

0 0-1 

+ 

+ 

+ 

+ 

+ 

OriginalMandateld 

Max35Text 

Identifikator osnovnog 
mandata iz originalne 
instrukcije 

3.76 

0 0-1 

+ 

+ 

+ 

Remmitancelnformation 

Remitnclnfrmation3 

Informacije o plaćanju 

3.76 

0 0-1 

+ 

+ 

+ 

+ 

UnstructuredRemmitanc 

e 

Maxl40Text 

Nestruktuirane 
informacije o plaćanju 

3.76 

0 0-1 

+ 

+ 

+ 

+ 

StructuredRemmitance 

StructuredRemittance 

Information6 

Struktuirane informacije 
o plaćanju 

3.76 

0 0-1 

+ 

+ 

+ 

+ 

+ 

ReferredDocument 

ReferredDocument 

Informationl 

Dokumentovanje 

plaćanja 

3.76 

0 0-1 

+ 

+ 

+ 

+ 

+ 

+ 

DocumentType 

ReferredDocument 

Typel 

Dokument 

3.76 

0 0-1 

+ 

+ 

+ 

+ 

+ 

+ 

+ Purport 

Max35Text 

Naziv dokumenta 

3.76 

0 0-1 

+ 

+ 

+ 

+ 

+ 

CreditorReference 

CreditorReference 

Informationl 

Referisanje poverioca na 
identifikator dužnika 

3.76 

0 0-1 

+ 

+ 

+ 

+ 

+ 

+ 

ReferenceType 

CreditorReference 

Typel 

Referenca 

3.76 

0 0-1 

+ 

+ 

+ 

+ 

+ 

+ 

+ Purport 

Max35Text 

Poziv na broj dužnika 

3.76 

0 0-1 

+ 

+ 

+ 

+ 

+ 

AdditionalRemmitan 

ce 

Maxl40Text 

Dodatne informacije o 
plaćanju 

3.102 

M 1 

+ 

+ 

+ 

Debtor 


Partyldntification 19 

Dužnika iz originalne 
instrukcije 

3.102 

М 1 

+ 

+ 

+ 

+ 

Debtorld 

Max35Text 

LD dužnika, matični broj 
ili Jmbg iz originalne 
instrukcije 

3.102 

М 1 

+ 

+ 

+ 

+ 

Name 

Max70Text 

Naziv dužnika iz 

originalne instrukcije 

3.102 

0 0-1 

+ 

+ 

+ 

+ 

PostAddress 

PostalAddress4 

Poštanska adresa 

dužnika iz originalne 
instrukcije 

3.102 

0 0-2 

+ 

+ 

+ 

+ 

+ 

Address 

Max70Text 

Adresa dužnika iz 

originalne instrukcije 

3.102 

М 1 

+ 

+ 

+ 

+ 

+ 

CountryCode 

CountryCode 

Kod države dužnika iz 
originalne instrukcije 

3.103 

М 1 

+ 

+ 

+ 

DebtorAccount 

CashAccount8 

Broj računa dužnika iz 
originalne instrukcije 

3.103 

М 1 

+ 

+ 

+ 

+ 

Accountld 

Account 

ldentification2 

Identifikacija računa 

dužnika iz originalne 
instrukcije 

3.103 

М 1 

+ 

+ 

+ 

+ 

+ 

IBANAccount 

IBANIdentifier 

fBAN broj računa 
dužnika iz originalne 
instrukcije 

3.104 

М 1 

+ 

+ 

+ 

DebtorAgent 

FinancialInstitution2 

Banka dužnika iz 

originalne instrukcije 

3.104 

М 1 

+ 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

ldentification4 

Identifikacija banke 

dužnika iz originalne 


Slobodan Babić \ Fakultet organizacionih nauka 


358 


















































Doktorska disertacija: Model interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama 










instrukcije 

3.104 

M 1 

+ 

+ 

+ 

+ 

+ 

BICAgent 

BIC Identifier 

BIC banke dužnika iz 
originalne instrukcije 

3.105 

0 0-1 

+ 

+ 

+ 

UltimateDebtor 

Institution2 

Pravni subjekt 

3.105 

0 0-1 

+ 

+ 

+ 

+ 

Identification 

Institution 

Identification 

Identifikacija pravnog 
subjekta 

3.105 

0 0-1 

+ 

+ 

+ 

+ 

+ 

Organisationld 

PIBIdentifier 

PIB dužnika 

Obavezno za pravne 
subjekte 

Za preduzetnike JMBG 

3.108 

M 1 

+ 

+ 

+ 

Creditor 

Party 

ldentificationl3 

Poverilac iz originalne 
instrukcije 

3.108 

M 1 

+ 

+ 

+ 

+ 

Name 

Max70Text 

Ime poverioca iz 

originalne instrukcije 

3.108 

0 0-1 

+ 

+ 

+ 

+ 

PostAddress 

PostalAddress4 

Poštanska adresa 

poverioca iz originalne 
instrukcije 

3.108 

0 0-2 

+ 

+ 

+ 

+ 

+ 

Address 

Max70Text 

Adresa poverioca iz 
originalne instrukcije 

3.108 

М 1 

+ 

+ 

+ 

+ 

+ 

CountryCode 

CountryCode 

Kod države poverioca iz 
originalne instrukcije 

3.109 

М 1 

+ 

+ 

+ 

CreditorAccount 

CashAccount8 

Broj računa poverioca 
iz originalne instrukcije 

3.109 

М 1 

+ 

+ 

+ 

+ 

Accountld 

Account 

ldentification2 

Identifikacija računa 

poverioca iz originalne 
instrukcije 

3.109 

М 1 

+ 

+ 

+ 

+ 

+ 

IBANAccount 

IBANIdentifier 

IBAN broj računa 
poverioca iz originalne 
instrukcije 

3.106 

М 1 

+ 

+ 

+ 

CreditorAgent 

FinancialInstitution2 

Banka poverioca iz 
originalne instrukcije 

3.106 

М 1 

+ 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

ldentification4 

Identifikacija banke 

poverioca iz originalne 
instrukcije 

3.106 

М 1 

+ 

+ 

+ 

+ 

+ 

BICAgent 

BIC Identifier 

BIC banke poverioca iz 
originalne instrukcije 

3.110 

OO-l 

+ 

+ 

+ 

UltimateCreditor 

Institution2 

Pravni subjekt 

3.110 

OO-l 

+ 

+ 

+ 

+ 

Identification 

Institution 

Identification 

Identifikacija pravnog 
subjekta 

3.110 

0 0-1 

+ 

+ 

+ 

+ 

+ 

Organisationld 

PIBIdentifier 

PIB poverioca 

Obavezno za pravne 
subjekte 

Za preduzetnike JMBG 


Specifikacija ISO kodova za Reversal transakcije: 


ISO kod 

Opis 

AC04 

Račun zatvoren 

AG02 

Pogrešan kod banke 

AM05 

Dupliran nalog 

MD01 

Nema validnog mandata 


ISO kod 

Opis 

MD05 

Instrukcija nije dospela 

MS02 

Nije naveden razlog od strane dužnika 

MS03 

Nije naveden razlog od strane banke 




POSLOVNA PRAVILA 


Index 

Element poruke 

Poslovna pravila 

1.1 

Messageld 

U sistemu je jedinstven na nivou pošiljaoca. 

U slučaju standardizacije identifikatora u domaćem platnom 
prometu, kontrolu vršiti prema usvojenom standardu 

1.2 

CreationDate 

Manji ili jednak od SettlementDate 
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1.5 

N umberT ransaction 

Veći od nule. 

Broj instrukcija u poruci, odnosno broj ponavljanja 

T ransactionlnformation 

1.7 

GroupReserval 

Vrednost: FALSE 

1.8 

TotalAmount .Amount 

Suma iznosa transakcija, odnosno 

suma ReversedSettlementAmount iz svake instrukcija 

1.8 

TotalAmount. Сиггепсу Code 

Vrednost: RSD 

1.9 

SettlementDate 

Veći od tekućeg datuma, a manji od tekućeg datuma+16 dana 

1.11 

SettlementMethodCode 

Vrednost: CLRG 

1.13 

C learingSy stemldentific ation 

Vrednost: KIB 

1.22 

InstructingAgent.BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

1.23 

InstructedAgent. BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

3.1 

Transactionld 

Predstavlja ID Reversal instrukcije koji generiše banka 
Poverioca i preko koga banka Poverioca identifikuje 
transakciju 

Maksimalna dužina: Max32Text., osim u slučaju greške kada 
je Max35Text. 

U slučaju odbijanja instrukcije od strane Procesora zbog 
ustanovljene greške (Reject procesora), drugom učesniku se 
dostavlja instrukcije u kojoj Transactionld započinje sa 
ERR+originalni Transactionld 

3.4 

OriginalEndT oEndld 

Predstavlja ID Reversal instrukcije koji generiše banka 
Poverioca i preko koga banka Poverioca identifikuje 
transakciju 

U slučaju standardizacije identifikatora u domaćem platnom 
prometu, kontrolu vršiti prema usvojenom standardu 

3.5 

OriginalT ransactionld 

TransactionlD iz originalne Collection instrukcije. 

Predstavlja ID originalne Collection instrukcije koji je generisala 
banka Poverioca. 

Kontrola postojanja instrukcije u evidenciji porcesora 

3.6 

OriginalSettlementAmount. 

Amount 

SettlementAmount iz originalne Collection instrukcije. 

Iznos originalne Collection instrukcije. 

Kontrola iznosa originalne transakcije koji je realizovan u 
kliringu, u evidenciji procesora 

3.6 

OriginalSettlementAmount. 

CurrencyCode 

Vrednost:RSD 

3.7 

ReversedSettlementAmount. 

Amount 

Uobičajeno, jednak OriginalSettlementAmount, 
ali može biti i različit u slučaju da je to predviđeno i 
dozvoljeno mandatom 

3.7 

ReversedSettlementAmount. 

CurrencyCode 

Vrednost:RSD 

3.17 

ReversalOriginator. 

BlCOriginator 

Podnosilac instrukcije može biti: 

- Banka Poverioca koja se identifikuje svojim BlC-om 

- Poverilac, koji se identifikuje svojim nazivom. 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

3.19 

ReversalReason. ReasonCode 

Kontrola koda razloga povraćaja u šifarniku kodova povraćaja 

3.21 

AdditionalReasonlnformation 

Ukoliko šifrirani kod razloga povraćaja ne objašnjava dovoljno 
razloge za povraćaja, može se zadati i njegov tekstualni opis. 

3.29 

OriginalTransactionReference 
. SettlementDate 

SettlementDate iz Header-a poruke u kojoj se nalazila 
originalna Collection instrukcija 

Kontrola SettlementDate iz originalne instrukcije, u evidenciji 
procesora 

3.31 

OriginalTransactionReference 
. RequestedDate 

RequestedDate iz originalne Collection instrukcije 

3.32 

Creditorld 

Struktura identifikatora u domaćem platnom prometu: 

Matični broj, dužine 8 - ukoliko se radi o Dužniku pravnom 
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licu 

JMBG, dužine 13 - ukoliko se radi o Dužniku fizičkom licu 
koje obavlja delatnost 

Kontrola dužine . 

3.45 

PaymentType. SequenceType 

SequenceType iz originalne Collection instrukcije: 

FRST - prvo plaćanje po višestrukom mandatu 

RECR - ostala plaćanja po višestrukom mandatu osim prvog i 
poslednjeg 

FINL - poslednje plaćanje po višestrukom mandatu 

ONEO - plaćanje po jednostukom mandatu 

3.46 

PaymentType.Category 

Purpose 

Vrednosti: 02, 03 

02 - za ovlašćenja kao osnov naplate koja su u posedu banke 
dužnika (poseban tip mandata definisan na od strane banaka na 
nivou UBS,) 

03 - za ostala ugovorna ovlašćenja kao osnov naplate (opšti tip 
mandata) 

3.57 

Mandatelnformation 

Mandateld 

Mandateld iz originalne Collection instrukcije 

3.57 

Mandatelnformation 

DateSignature 

DateSignature iz originalne Collection instrukcije 

3.57 

Mandatelnformation 

Amendmentlndicator 

Amendmentlndicator iz originalne Collection instrukcije 

3.57 

Mandatelnformation 

OriginalMandateld 

Amendmentlnformation iz originalne Collection instrukcije. 

ID osnovnog mandata ukoliko je Amendmentlndicator iz 
originalne Collection instrukcije=TRUE 

3.76 

Remmitancelnformation 

Remmitancelnformation iz originalne Collection instrukcije 

3.102 

Debtor 

Debtor iz originalne Collection instrukcije 

3.103 

DebtorAccount. 

IBANAccount 

Struktura broja računa u domaćem platnom prometu: 

DDKKBBBnnnnnnnnnnnnnKB 

Gde je: 

DD - oznaka države (fiksna vrednost RS za Srbiju) 

KK - kontrolni broj po modelu 97 za ceo IBAN račun (fiksna 
vrednost 35 za Srbiju) 

BBB - šifra banke koja odgovara BIC-u banke dužnikž 
(DebtorAgent) 

nnnnnnnnnnnnn - broj računa 

KB - kontrolni broj za broj računa bez oznake države (DD) i 
kontrolnog broja (KK) 

3.104 

DebtorAgent. BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

3.105 

U ltimateD ebtor. Identification 
.Organisationld 

PIB pravnog subjekta dužnika 

Kontrola: dužina 9 (za pravna lica) ili 13 (za preduzetnike) 
znakova 

3.108 

Creditor 

Creditor iz originalne Collection instrukcije (svi atributi iz 
originalne instrukcija) 

3.109 

C reditor Acc ount. 
IBANAccount 

Struktura broja računa u domaćem platnom prometu: 

DDKKBBBnnnnnnnnnnnnnKB 

Gde je: 

DD - oznaka države (fiksna vrednost RS za Srbiju) 

KK - kontrolni broj po modelu 97 za ceo IBAN račun (fiksna 
vrednost 35 za Srbiju) 

BBB - šifra banke koja odgovara BIC-u banke poverioct 

(CreditorAgent) 

nnnnnnnnnnnnn - broj računa 

KB - kontrolni broj za broj računa bez oznake države (DD) i 
kontrolnog broja (KK) 

3.106 

CreditorAgent. BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

3.110 

UltimatCreditor.Identification 

.Organisationld 

PIB pravnog subjekta poverioca, Kontrola: dužina 9 (za pravna 
lica) ili 13 (za preduzetnike) znakova 
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PORUKA pacs.002.001.02 REJECT 
Struktura: SerbianStatus 

• Koristi se za odbijanje transakcija direktnog zaduženja (nerealizovanih) 

• Generiše je banka dužnika i Ispostavlja procesoru ili procesor 

• Poruka se sastoji od zaglavlja (Group Header) koje nosi zajedničke informacije svih transakcija 
direktnog zaduženja koje se odbijaju iz poruke i tela poruke (Transaction Information) koje nosi 
informacije o pojedinačnim transakcijama direktnog zaduženja koje se odbijaju (nerealizovanim). 

• Struktura poruke: 


Index 

Kardin 

alnost 

Element poruke 

Tip 

Opis i poslovna 
pravila 

1.0 

M 1 

+ 

Header 

GroupHeaderl2 

Zaglavlje poruke 

1.1 

M 1 

+ 

+ 

Messageld 

Max35Text 

Jedinstveni 
identifikator poruke 
koji formira 

pošiljalac poruke 

1.2 

M 1 

+ 

+ 

CreationDate 

ISODateTime 

Datum kreiranja 

poruke 

1.7 

M 1 

+ 

+ 

InstructingAgent 

Financial 

Institution2 

Pošiljalac poruke 

1.7 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitutionld 

entifrcation4 

Identifikacija 
pošiljaoca poruke 

1.7 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCIdentifier 

BIC pošiljaoca 

poruke 

1.8 

М 1 

+ 

+ 

InstructedAgent 

Financial 

Institution2 

Primalac poruke 

1.8 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitutionld 

entification4 

Identifikacija 
primaoca poruke 

1.8 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCIdentifier 

BIC primaoca poruke 

3.0 

М 1-n 

+ 

Т ransactionlnformation 

PaymentTransactio 

nInformationl2 

Telo poruke 

instrukcije 
odbijanja (Reject) 

3.1 

М 1 

+ 

+ 

Transactionld 

Max35Text 

Jedinstveni Id 

transakcije 
podnosioca 
instrukcije 

3.4 

М 1 

+ 

+ 

OriginalEndT oEndld 

Max35Text 

Poziv na broj 

poverioca iz originalne 
instrukcije 

3.5 

М 1 

+ 

+ 

OriginalT ransactionld 

Max35Text 

Id transakcije banke 
Poverioca iz originalne 
instrukcije 

3.6 

М 1 

+ 

+ 

TransactionStatus 

T ransactionlndividua 
lStatus2Code 

Vrednost: RJCT 

3.7 

М 1 

+ 

+ 

StatusReasonlnformation 

StatusReasonlnfor 

mationJ 

Informacije o 

razlozima odbijanja 

3.8 

М 1 

+ 

+ 

+ 

StatusOriginator 

Party 

Identificationl4 

Identifikacija 
inicijatora odbijanja 

instrukcije (banka, 

Procesor ili Dužnik) 

3.8 

{or 

+ 

+ 

+ 

+ 

Originatorld 

PartyOrganisation 1 
Choice 

Identifikacija 
inicijatora odbijanja 
instrukcije (banka ili 
Procesor) 

3.8 

М 1 

+ 

+ 

+ 

+ 

+ 

Originator 

Organisation 

Identification3 

Identifikacija 
inicijatora odbijanja 
instrukcije (banka ili 
Procesor) 
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3.8 

M 1 

+ 

+ 

+ 

+ 

+ 

+ 

BlCOriginator 

BlCIdentifier 

BIC banke ili 

Procesora, inicijatora 
odbijanja instrukcije 

3.8 

or} 

+ 

+ 

+ 

+ 

OriginatorName 

Max35Text 

Naziv Dužnika 

inicijatora odbijanje 
instrukcije 

3.9 

M 1 

+ 

+ 

+ 

StatusReason 

StatusReason3 

Choice 

Kodirani razlog za 
odbijanje instrukcije 

3.10 

M 1 

+ 

+ 

+ 

+ 

StatusCode 

T ransactionReturnRe 
ason4Code 

Kod razloga za 

odbijanje instrukcije 

3.12 

0 0-1 

+ 

+ 

+ 

AdditionalReasonlnformatio 

n 

Maxl05Text 

Dodatno obrazloženje 
za odbijanje 

instrukcije. 

3.17 

M 1 

+ 

+ 

OriginalT ransactionReferenc 
е 

OriginalT ransaction 
Reference8 

Podaci iz originalne 
instrukcije 

3.18 

M 1 

+ 

+ 

+ 

OriginalSettlementAmount 

ЕигоМах 15 Amount 

Iznos transakcije iz 
originalne instrukcije. 

3.18 

М 1 

+ 

+ 

+ 

+ 

Amount 

Decimal, 15,2 

Iznos transakcije u 
domaćoj valuti iz 
originalne instrukcije 

3.18 

М 1 

+ 

+ 

+ 

+ 

CurrencyCode 

EuroCurrencyCode 

Kod domaće valute iz 
originalne instrukcije 

3.24 

М 1 

+ 

+ 

+ 

SettlementDate 

ISODate 

Datum 

međubankarskog 
obračuna originalne 
transakcije 

3.26 

М 1 

+ 

+ 

+ 

RequestedDate 

ISODate 

Datum dospeća 

(DueDate) iz 

originalne transakcije 

3.27 

М 1 

+ 

+ 

+ 

Creditorldlnformation 

Creditorldentification 

Information 

Informacija c 

identifikaciji Poveriocć 
iz originalne instrukcije 

3.27 

М 1 

+ 

+ 

+ 

+ 

Creditorld 

Max35Text 

Id Poverioca, matični 
broj ili Jmbg iz 
originalne instrukcije. 

3.40 

М 1 

+ 

+ 

+ 

PaymentType 

PaymentType 

lnformation9 

Tip plaćanja iz 

originalne instrukcije 

3.48 

М 1 

+ 

+ 

+ 

+ 

SequenceType 

SequenceTypel 

Code 

Kod tipa plaćanja iz 
originalne instrukcije 

3.49 

М 1 

+ 

+ 

+ 

+ 

CategoryPurpose 

CategoryPurpose 

Code 

Vrednosti: 

02 - za ovlašćenje 

defmisana od strane 
banaka na nivou UBS 
03 - za ostala 

ugovorna ovlašćenja 

3.52 

М 1 

+ 

+ 

+ 

Mandatelnformation 

MandateRelated 

lnformation4 

Informacije o 

mandatu ili aneksu iz 
originalne instrukcije 

3.52 

М 1 

+ 

+ 

+ 

+ 

Mandateld 

Max35Text 

Identifikacija mandata 
ili aneksa iz originalne 
instrukcije 

3.52 

М 1 

+ 

+ 

+ 

+ 

DateSignature 

ISODate 

Datum potpisivanja 
mandata ili aneksa iz 
originalne instrukcije 

3.52 

М 1 

+ 

+ 

+ 

+ 

Amendmentlndicator 

T rueF alselndicator 

Indikator aneksa iz 
originalne instrukcije 

3.52 

0 0-1 

+ 

+ 

+ 

+ 

Amendmentlnformation 

Amendment 

lnformationDetails4 

Informacije o 

osnovnom mandatu iz 
originalne instrukcije 
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3.52 

0 0-1 

+ 

+ 

+ 

+ 

+ 

OriginalMandateld 

Max35Text 

Identifikator 
osnovnog mandata iz 
originalne instrukcije 

3.71 

0 0-1 

+ 

+ 

+ 

Remmitancelnformation 

Remittance 

Information3 

Informacije o 

plaćanju 

3.71 

0 0-1 

+ 

+ 

+ 

+ 

UnstructuredRemmitanc 

e 

Maxl40Text 

Nestruktuirane 
informacije o plaćanju 

3.71 

0 0-1 

+ 

+ 

+ 

+ 

StructuredRemmitance 

StructuredRemittance 

lnformation6 

Struktuirane 
informacije o plaćanju 

3.71 

0 0-1 

+ 

+ 

+ 

+ 

+ 

ReferredDocument 

ReferredDocument 

Informationl 

Dokumentovanje 

plaćanja 

3.71 

0 0-1 

+ 

+ 

+ 

+ 

+ 

+ 

DocumentType 

ReferredDocument 

Typel 

Dokument 

3.71 

0 0-1 

+ 

+ 

+ 

+ 

+ 

+ 

+ 

Purport 

Max35Text 

Naziv dokumenta 

3.71 

0 0-1 

+ 

+ 

+ 

+ 

+ 

CreditorReference 

Creditor Reference 
Informationl 

Referisanje poverioca 
na identifikator 

dužnika 

3.71 

0 0-1 

+ 

+ 

+ 

+ 

+ 

+ 

ReferenceType 

CreditorReference 

Typel 

Referenca 

3.71 

0 0-1 

+ 

+ 

+ 

+ 

+ 

+ 

+ 

Purport 

Max35Text 

Poziv na broj dužnika 

3.71 

0 0-1 

+ 

+ 

+ 

+ 

+ 

AdditionalRemmitan 

ce 

Maxl40Text 

Dodatne informacije o 
plaćanju 

3.97 

M 1 

+ 

+ 

+ 

Debtor 

Party 

Identificationl9 

Dužnika iz originalne 
instrukcije 

3.97 

M 1 

+ 

+ 

+ 

+ 

Debtorld 

Max35Text 

ID dužnika, matični 
broj ili Jmbg iz 
originalne instrukcije 

3.97 

M 1 

+ 

+ 

+ 

+ 

Name 

Max70Text 

Naziv dužnika iz 
originalne instrukcije 

3.97 

0 0-1 

+ 

+ 

+ 

+ 

PostAddress 

PostalAddress4 

Poštanska adresa 

dužnika iz originalne 
instrukcije 

3.97 

0 0-2 

+ 

+ 

+ 

+ 

+ 

Address 

Max70Text 

Adresa dužnika iz 
originalne instrukcije 

3.97 

М 1 

+ 

+ 

+ 

+ 

+ 

CountryCode 

CountryCode 

Kod države dužnika iz 
originalne instrukcije 

3.98 

М 1 

+ 

+ 

+ 

DebtorAccount 

CashAccount8 

Broj računa dužnika 
iz originalne 

instrukcije 

3.98 

М 1 

+ 

+ 

+ 

+ 

Accountld 

Account 

Identification2 

Identifikacija računa 
dužnika iz originalne 
instrukcije 

3.98 

М 1 

+ 

+ 

+ 

+ 

+ 

IBANAccount 

IBANIdentifier 

IBAN broj računa 
dužnika iz originalne 
instrukcije 

3.99 

М 1 

+ 

+ 

+ 

DebtorAgent 

Financial 

Institution2 

Banka dužnika iz 
originalne instrukcije 

3.99 

М 1 

+ 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

Identification4 

Identifikacija banke 

dužnika iz originalne 
instrukcije 

3.99 

М 1 

+ 

+ 

+ 

+ 

+ 

BICAgent 

BIC Identifier 

BIC banke dužnika iz 
originalne instrukcije 

3.100 

0 0-1 

+ 

+ 

+ 

UltimateDebtor 

Institution2 

Pravni subjekt 

3.100 

0 0-1 

+ 

+ 

+ 

+ 

Identification 

Institution 

Identification 

Identifikacija pravnog 
subjekta 

3.100 

0 0-1 

+ 

+ 

+ 

+ 

+ 

Organisationld 

PIBldentifier 

PIB dužnika 

Obavezno za pravne 
subjekte 

Za preduzetnike 
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JMBG 

3.103 

M 1 

+ 

+ 

+ 

Creditor 

Party 

Identificationl3 

Poverilac iz 

originalne instrukcije. 

3.103 

M 1 

+ 

+ 

+ 

+ 

Name 

Max70Text 

Ime poverioca iz 
originalne instrukcije 

3.103 

0 0-1 

+ 

+ 

+ 

+ 

PostAddress 

PostalAddress4 

Poštanska adresa 

poverioca iz 

originalne instrukcije 

3.103 

0 0-2 

+ 

+ 

+ 

+ 

+ 

Address 

Max70Text 

Adresa poverioca iz 
originalne instrukcije 

3.103 

M 1 

+ 

+ 

+ 

+ 

+ 

CountryCode 

CountryCode 

Kod države poverioca 
iz originalne 

instrukcije 

3.104 

M 1 

+ 

+ 

+ 

CreditorAccount 

CashAccount8 

Broj računa 

poverioca iz 

originalne instrukcije 

3.104 

М 1 

+ 

+ 

+ 

+ 

Accountld 

Account 

Identification2 

Identifikacija računa 
poverioca iz 

originalne instrukcije 

3.104 

М 1 

+ 

+ 

+ 

+ 

+ 

IBANAccount 

IBANldentifier 

IBAN broj računa 
poverioca iz 

originalne instrukcije 

3.101 

М 1 

+ 

+ 

+ 

CreditorAgent 

Financial 

Institution2 

Banka poverioca iz 
originalne instrukcije 

3.101 

М 1 

+ 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

Identification4 

Identifikacija banke 

poverioca iz originalne 
instrukcije 

3.101 

М 1 

+ 

+ 

+ 

+ 

+ 

BICAgent 

BlCIdentifier 

BIC banke poverioca 
iz originalne 

instrukcije 

3.105 

0 0-1 

+ 

+ 

+ 

UltimateCreditor 

Institution2 

Pravni subjekt 

3.105 

0 0-1 

+ 

+ 

+ 

+ 

Identification 

Institution 

Identification 

Identifikacija pravnog 
subjekta 

3.105 

0 0-1 

+ 

+ 

+ 

+ 

+ 

Organisationld 

PIBldentifier 

PIB poverioca 
Obavezno za pravne 
subjekte 

Za preduzetnike 

JMBG 


Specifikacija ISO kodova za Reject transakcije: 


ISO kod 

Opis 

AC01 

Pogrešan broj računa 

AC04 

Račun zatvoren 

AC06 

Račun blokiran 

AG01 

Transakcija zabranjena 

AG02 

Pogrešan kod banke 

AMOl 

Nula iznos 

AM02 

Nedopušten račun 

AM03 

Nedopuštena valuta 

AM04 

Nedovoljno sredstava 

AM05 

Dupliran nalog 

AM06 

Premali iznos 

AM07 

Blokiran iznos 

AM09 

Pogrešan iznos 

AM10 

Pogrešna kontrolna suma 

BE01 

Nesaglasan krajnji korisnik 

BE04 

Pogrešna adresa poverioca 

BE06 

Neprepoznat dužnik 


ISO kod 

Opis 

BE07 

Pogrešna adresa dužnika 

DT01 

Pogrešan datum 

EDOl 

Ne postoji korespodentna banka 

ED03 

Traženo stanje 

MD01 

Nema validnog mandata 

MD02 

Pogrešne informacije o mandatu 

MD03 

Pogrešan format podatka o razlozima 

MD04 

Pogrešan format podataka za indikatore 

MD06 

Dužnik je podneo Refunda zahtev 

MD07 

Dužnikje umro 

MS02 

Nije naveden razlog od strane dužnika 

MS03 

Nije naveden razlog od strane banke 

NARR 

Opisno 

RC01 

Pogrešan identifikator banke 

RFOl 

Referenca transakcije nije jedinstvena 

TMOl 

Cutt off time (istek vremena) 

RROl 

Razlozi regulatora (procesora) 
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POSLOVNA PRAVILA 


Index 

Element poruke 

Poslovna pravila 

1.1 

Messageld 

U sistemu je jedinstven na nivou pošiljaoca. 

U slučaju standardizacije identifikatora u domaćem 
platnom prometu, kontrolu vršiti prema usvojenom 
standardu 

1.2 

CreationDate 

Manji ili jednak od tekućeg datume 

1.7 

InstructingAgent. BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za 
direktna zaduženja 

1.8 

InstructedAgent. BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za 
direktna zaduženja 

3.1 

Transactionld 

Predstavlja ID Return instrukcije koji generiše banka 
Dužnika za odbijanje Collection instrukcije, odnosno 
banka Poverioca za odbijanje Return/Refund 
instrukcija 

3.4 

OriginalEndT oEndld 

EndToEndlD iz originalne Collection instrukcije. 
Predstavlja ID originalne Collection instrukcije koji je 
generisao Poverilac, odnosno ,,NONPROVIDED“ za 
originalnu Return/Refund instrukciju 

3.5 

OriginalTransactionld 

Transactionld iz originalne Collection instrukcije. 
Predstavlja ID originalne Collection instrukcije koji je 
generisala banka Poverioca, 

odnosno originalne Return/Refund instrukcije koji je 
generisala banka Dužnika 

Kontrola postojanja instrukcije u evidenciji procesora 

3.6 

TransactionStatus 

Vrednost: RJCT 

3. 8 

StatusOriginator. 

BlCOriginator 

Podnosilac instrukcije može biti: 

- Banka Poverioca, Banka Dužnika ili Procesor, koji se 
identifikuju BlC-om 

- Dužnik, koji se identifikuje svojim nazivom 

Mora biti u evidenciji aktivnih učesnika kliringa za 
direktna zaduženja 

3.10 

StatusReason. StatusCode 

Kontrola koda razloga povraćaja u šifarniku kodova 
odbijanja 

3.12 

AdditionalReasonlnformation 

Ukoliko šifrirani kod razloga odbijanja ne objašnjava 
dovoljno razloge odbijanja, može se zadati i njegov 
tekstualni opis. 

3.18 

Original Settlement Amo unt. 
Amount 

SettlementAmount iz originalne Collection instrukcije, 
odnosno . 

ReturnSettlementAmount iz Return/Refund 

instrukcije. 

Veći od nule 

3.18 

OriginalSettlementAmount. 

CurrencyCode 

Vrednost: RSD 

3.24 

OriginalT ransactionReference 
.SettlementDate 

SettlementDate iz Header-a poruke u kojoj se nalazila 
originalna instrukcija 

Kontrola SettlementDate iz originalne instrukcije, u 
evidenciji procesora 

3.26 

OriginalT ransactionReference 
.RequestedDate 

RequestedDate iz originalne Collection instrukcije 

3.27 

Creditorld 

Struktura identifikatora u domaćem platnom prometu: 
Matični broj, dužine 8 - ukoliko se radi o Dužniku 
pravnom licu 

JMBG, dužine 13 - ukoliko se radi o Dužniku 
fizičkom licu koje obavlja delatnost 

Kontrola dužine . 

3.48 

PavmenfI vpc. SequenceType 

SequenceType iz originalne Collection instrukcije: 
FRST - prvo plaćanje po višestrukom mandatu 
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RECR - ostala plaćanja po višestrukom mandatu osim 
prvog i poslednjeg 

FINL - poslednje plaćanje po višestrukom mandatu 
ONEO - plaćanje po jednostukom mandatu 

3.49 

PaymentType.Category 

Purpose 

Vrednosti: 02, 03 

02 - za ovlašćenja kao osnov naplate koja su u posedu 
banke dužnika (poseban tip mandata defmisan na od 
strane banaka na nivou UBS,) 

03 - za ostala ugovorna ovlašćenja kao osnov naplate 
(opšti tip mandata) 

3.52 

Mandatelnformation 

Mandateld 

Mandatld iz originalne instrukcije 

3.52 

Mandatelnformation 

DateSignature 

DateSignature iz originalne instrukcije 

3.52 

Mandatelnformation 

Amendmentlndicator 

Amendmentlndicator iz originalne instrukcije 

3.52 

Mandatelnformation 

OriginalMandateld 

Amendmentlnformation iz originalne instrukcije. 

ID osnovnog mandata ukoliko je 

Amendmentlndicator iz originalne instrukcije=TRUE 

3.71 

Remmitancelnformation 

Remmitancelnformation iz originalne Collection 
instrukcije 

3.97 

Debtor 

Debtor iz originalne Collection instrukcije 

3.98 

DebtorAccount. 

IBANAccount 

Struktura broja računa u domaćem platnom prometu: 

DDKKBBBnnnnnnnnnnnnnKB 

Gde je: 

DD - oznaka države (fiksna vrednost RS za Srbiju) 

KK - kontrolni broj po modelu 97 za ceo IBAN 
račun (fiksna vrednost 35 za Srbiju) 

BBB - šifra banke koja odgovara BIC-u banke dužnika 
(DebtorAgent) 

nnnnnnnnnnnnn - broj računa 

KB - kontrolni broj za broj računa bez oznake države 
(DD) i kontrolnog broja (KK) 

3.99 

DebtorAgent. BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za 
direktna zaduženja 

3.100 

UltimateDebtor.ldentification 

.Organisationld 

PIB pravnog subjekta dužnika 

Kontrola: dužina 9 (za pravna lica) ili 13 (za 
preduzetnike) znakova 

3.103 

Creditor 

Creditor iz originalne Collection instrukcije (svi 
atributi iz originalne instrukcija) 

3.104 

CreditorAccount. 

IBANAccount 

Struktura broja računa u domaćem platnom prometu: 

DDKKBBBnnnnnnnnnnnnnKB 

Gde je: 

DD - oznaka države (fiksna vrednost RS za Srbiju) 

KK - kontrolni broj po modelu 97 za ceo IBAN 
račun (fiksna vrednost 35 za Srbiju) 

BBB - šifra banke koja odgovara BIC-u bankc 
poverioca (CreditorAgent) 
nnnnnnnnnnnnn - broj računa 

KB - kontrolni broj za broj računa bez oznake države 
(DD) i kontrolnog broja (KK) 

3.101 

CreditorAgent. BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za 
direktna zaduženja 

3.105 

UltimateCreditor. 
Identification .Organisationld 

PIB pravnog subjekta poverioca 

Kontrola: dužina 9 (za pravna lica) ili 13 (za 
preduzetnike) znakova 
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PORUKA paos.002.001.01 REQUEST&CANCELLATION 
Struktura: SerbianCancel 

• Koristi se za povlačenje ispostavljnih transakcija direktnog zaduženja (nerealizovanih) 

• Generiše je banka koja je ispostavila transakciju direktnog zaduženja i dostavlja procesoru 

• Poruka se sastoji od zaglavlja (Group Header) koje nosi zajedničke informacije svih transakcija 
direktnog zaduženja koje se povlače iz poruke i tela poruke (Transaction Information) koje nosi 
informacije o pojedinačnim transakcijama direktnog zaduženja koje se povlače (nerealizovanim). 

• Struktura poruke: 


Index 

Kardin 

alnost 

Element poruke 

Tip 

Opis 

1.0 

M 1 

+ 

Header 

GroupHeaderl22 

Zaglavlje poruke 

1.1 

M 1 

+ 

+ 

Messageld 

Max35Text 

Jedinstveni 

identifikator poruke 

koji formira pošiljalac 
poruke 

1.2 

M 1 

+ 

+ 

CreationDate 

ISODateTime 

Datum kreiranja poruke 

1.3 

M 1 

+ 

+ 

InstructingAgent 

LinancialInstitution2 

Pošiljalac poruke 

1.3 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

Identification4 

Identifikacija 
pošiljaoca poruke 

1.3 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC pošiljaoca poruke 

1.4 

М 1 

+ 

+ 

InstructedAgent 

FinancialInstitution2 

Primalac poruke 

1.4 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

ldentification4 

Identifikacija primaoca 
poruke 

1.4 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC primaoca poruke 

2.0 

М 1-n 

+ 

Transactionlnformation 

T ransactionlnformati 
onCancel 

Telo poruke za 

povlačenje poruke ili 
pojedinačne instrukcije 

2.1 

М 1 

+ 

+ 

Transactionld 

Max35Text 

Jedinstveni Id 

transakcije podnosioca 
instrukcije 

2.2 

М 1 

+ 

+ 

OriginalT ransactionlnform 
ation 

OriginalT ransaction 
Information2 

Identifikacija originalne 
poruke 

2.3 

М 1 

+ 

+ 

+ 

OriginalMessageld 

Max35Text 

Jedinstveni 

identifikator originalne 
poruke 

2.4 

М 1 

+ 

+ 

+ 

OriginalMessageNam 

e 

Max35Text 

Naziv originalne 

poruke 

(pacs.xxx.xxx.xx) . 

2.5 

0 0-1 

+ 

+ 

+ 

OriginalCreationDate 

ISODateTime 

Datum kreiranja 

originalne poruke 

2.6 

0 0-n 

+ 

+ 

OriginalT ransactionld 

Max35Text 

Id transakcije banke 
podnosioca instrukcije iz 
originalne instrukcije 

2.7 

М 1 

+ 

+ 

TransactionStatus 

T ransactionlndividual 
Status2Code 

Vrednost: CNCL 


POSLOVNA PRAVILA 


Index 

Element poruke 

Poslovna pravila 

1.1 

Messageld 

U sistemu je jedinstven na nivou pošiljaoca. 

U slučaju standardizacije identifikatora u domaćem platnom 
prometu, kontrolu vršiti prema usvojenom standardu 

1.2 

CreationDate 

Manji ili jednak od tekućeg datume 

1.3 

InstructingAgent. BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

1.4 

InstructedAgent. BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 
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2.1 

Transactionld 

Predstavlja ID Reques&Cancellation instrukcije koji generiše 
banka koja je uputila originalnu instrukciju 

2.3 

OriginalMessageld 

Messageld iz Header-a poruke u kojoj se nalazila originalna 
instrukcija. 

Predstavljajedinstveni identifikator poruke u kojoj se nalazi 
originalna instrukcije 

Kontrola postojanja poruke u evidenciji procesora 

2.4 

OriginalMessageName 

Može biti: 

pacs.003.001.01, za povlačenje Collection instrukcije 
pacs.004.001.01, za povlačenje Return/Refund instrukcija 
pacs.007.001.01, za povlačenje Reversal instrukcija 

2.5 

OriginalCreationDate 

CreationDate iz Header-a poruke u kojoj se nalazila originalna 
instrukcija 

2.6 

OriginalTransactionld 

TransactionlD iz originalne instrukcije. 

Predstavlja ID originalne instrukcije koja se povlači 

Kontrola postojanja instrukcije u evidenciji procesora 

2.7 

TransactionStatus 

Vrednost: CNCL 


PORUKA paos.003.001.01 BALANCE 
Struktura: SerbianBalance 

• Izvod obračunskog računa učesnika u kliringu 

• Generiše je procesor i dostavlja bankama učesnicima. 

• Poruka se sastoji od zaglavlja (Group Header) koje nosi zajedničke informacije svih transakcija 
direktnog zaduženja koje se nalaze u izvodu i tela poruke (Transaction Information) koje nosi 
informacije o pojedinačnim transakcijama direktnog zaduženja koje su realizovane preko 
obračunskog računa banke učesnika u klirinškom ciklusu. 

• Struktura poruke: 


Index 

Kardin 

alnost 

Element poruke 

Tip 

Opis 

1.0 

M 1 

+ 

Header 

GroupHeaderl22 

Zaglavlje poruke 

1.1 

M 1 

+ 

+ 

Messageld 

Max35Text 

Jedinstveni identifikator 
poruke koji formira 
pošiljalac poruke 

1.2 

M 1 

+ 

+ 

CreationDate 

ISODateTime 

Datum kreiranja poruke 

1.3 

M 1 

+ 

+ 

InstructingAgent 

Financial 

Institution2 

Pošiljalac poruke 

1.3 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

Identification4 

Identifikacija pošiljaoca 
poruke 

1.3 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCIdentifier 

BIC pošiljaoca poruke 

1.4 

М 1 

+ 

+ 

InstructedAgent 

Financial 

Institution2 

Primalac poruke 

1.4 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

ldentification4 

Identifikacija primaoca 
poruke 

1.4 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC primaoca poruke 

2.0 

М 1 

+ 

Transactionlnformation 

Transaction 

InfrmationBalance 

Telo poruke za izvod 
obračunskog računa 

učesnika u kliringu 

2.1 

М 1 

+ 

+ 

Balanceld 

Max35Text 

Idetifikator izvoda, 

jedinstven na nivou 
učesnika i poslovne 
godine 

2.2 

М 1 

+ 

+ 

LastPage 

Y esNolndicator 

Indikator poslednje 

poruke (TRUE) ukoliko 
se izvod šalje u više 
poruka 

2.3 

М 1 

+ 

+ 

SettlementDate 

ISODate 

Datum 

međubankarskog 

obračuna 
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2.4 

M 1 

+ 

+ 

Settlementlnformation 

Settlement 

Information 

Informacije o obračunu 

2.4 

M 1 

+ 

+ 

+ 

SettlementMethodC ode 

SettlementMethod2 

Code 

Vrednost: CLRG 

2.5 

M 1-n 

+ 

+ 

ClearingCycle 

ClearingCycle 

Informacije o ciklusu 
kliringa 

2.6 

M 1 

+ 

+ 

+ 

ClearinCycleld 

Maxl6Text 

ldentifikacija klirinškog 
ciklusa 

2.7 

M 1 

+ 

+ 

+ 

Trn 

Maxl6Text 

Identifator poruke 

MT202 kojom je 

realizovana neto pozicija 
učesnika 

2.8 

OO-n 

+ 

+ 

+ 

BalanceLine 

BalanceLine 

Realizovane transakcije 

2.9 

М 1 

+ 

+ 

+ 

+ 

Messageldentification 

Message 

Identification 

Identifikacija poruke 

2.10 

М 1 

+ 

+ 

+ 

+ 

+ 

Messageld 

Max35Text 

Jedinstveni identifikator 
poruke koji formira 
pošiljalac poruke 

2.11 

М 1 

+ 

+ 

+ 

+ 

+ 

MessageName 

Max35Text 

Naziv poruke 

(pacs.xxx.xxx.xx) 

2.12 

М 1 

+ 

+ 

+ 

+ 

+ 

CreationDate 

ISODateTime 

Datum kreiranja poruke 

2.13 

М 1 

+ 

+ 

+ 

+ 

+ 

InstructingAgent 

Financial 

lnstitution2 

Pošiljalac poruke 

2.13 

М 1 

+ 

+ 

+ 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

ldentification4 

Identifikacija pošiljaoca 
poruke 

2.13 

М 1 

+ 

+ 

+ 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC pošiljaoca poruke 

2.14 

М 1 

+ 

+ 

+ 

+ 

+ 

InstructedAgent 

Financial 

Institution2 

Primalac poruke 

2.14 

М 1 

+ 

+ 

+ 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

ldentification4 

Identifikacija primaoca 
poruke 

2.14 

М 1 

+ 

+ 

+ 

+ 

+ 

+ 

+ 

BlCAgent 

BlCldentifier 

BIC primaoca poruke 

2.15 

М 1 

+ 

+ 

+ 

+ 

OriginalT ransactionld 

Max35Text 

Id transakcije podnosioca 

2.16 

М 1 

+ 

+ 

+ 

+ 

SettlementType 

SettlementType 

Vrsta transakcije u 
odnosu na račun 

Učesnika: CREDIT, 

DEBIT 

2.17 

М 1 

+ 

+ 

+ 

+ 

Settlement Amo unt 

EuroMaxl5 

Amount 

Iznos transakcije 

2.17 

М 1 

+ 

+ 

+ 

+ 

+ 

Amount 

Decimal, 15,2 

Iznos transakcije u 
domaćoj valuti 

2.17 

М 1 

+ 

+ 

+ 

+ 

+ 

CurrencyCode 

EuroCurrencyC ode 

Kod domaće valute:RSD 

2.18 

М 1 

+ 

+ 

+ 

+ 

DebtorAccount 

CashAccount8 

Broj računa zaduženja 

2.18 

М 1 

+ 

+ 

+ 

+ 

+ 

Accountld 

Account 

ldentification2 

Identifikacija broja 

računa zaduženja 

2.18 

М 1 

+ 

+ 

+ 

+ 

+ 

+ 

IBANAccount 

IBANldentifier 

IBAN broj računa 
zaduženja 

2.19 

М 1 

+ 

+ 

+ 

+ 

CreditorAccount 

CashAccount8 

Broj računa odobrenja 

2.19 

М 1 

+ 

+ 

+ 

+ 

+ 

Accountld 

Account 

ldentification2 

Identifikacija računa 

odobrenja 

2.19 

М 1 

+ 

+ 

+ 

+ 

+ 

+ 

IBANAccount 

IBANldentifier 

IBAN broj računa 
odobrenja 

2.20 

М 1 

+ 

+ 

+ 

+ 

StructuredRemmitance 

Structured 

Remmitancel 

Struktuirane informacije 
o plaćanju 

2.21 

0 0-1 

+ 

+ 

+ 

+ 

+ 

Purpose 

PurposelChoice 

Informacija o svrsi 

plaćanja 

2.21 

0 0-1 

+ 

+ 

+ 

+ 

+ 

+ 

Purport 

Max35Text 

Svrha plaćanja iz 

instrukcije zaduženja 

2.22 

0 0-1 

+ 

+ 

+ 

+ 

+ 

Reasonlnformation 

Reasonlnformation 

Razlog povraćaja za 
transakcije Retum/ 
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Refund i Reversal 

2.22 

0 0-1 

+ 

+ 

+ 

+ 

+ 

+ 

Reason 

Reason3 Choice 

Kodirani razlog 

povraćaja 

2.22 

0 0-1 

+ 

+ 

+ 

+ 

+ 

+ 

+ ReasonCode 

Transaction 

ReasonCode 

Kod razloga povraćaja 

2.23 

0 0-1 

+ 

+ 

+ 

+ 

UnstructuredRemmita 

nce 

Maxl40Text 

Nestruktuirane 
informacije o plaćanju 


POSLOVNA PRAVILA 


Index 

Element poruke 

Poslovna pravila 

1.1 

Messageld 

U sistemu je jedinstven na nivou pošiljaoca. 

U slučaju standardizacije identifikatora u domaćem platnom 
prometu, kontrolu vršiti prema usvojenom standardu 

1.2 

CreationDate 

Jednak tekućem datumu 

1.3 

InstructingAgent. BICAgent 

BIC Procesora 

1.4 

InstructedAgent. BICAgent 

Mora biti u evidenciji učesnika kliringa za direktna zaduženja 

2.1 

Balanceld 

ID izvoda koji generiše Procesor, jedinstven na nivou 
učesnika u toku godine. 

Struktura identifikatora: BlC+godina+redni broj izvoda u 
godini 

2.2 

LastPage 

Ukoliko se izvod upućuje učesniku u jednoj poruci, vrednost je 
TRUE. 

Ukoliko se izvod upućuje učesniku u više poruka, samo 
poslednja sadrži vrednost TRUE, a ostale vrednost FALSE. 

2.3 

SettlementDate 

Datum u kome je realizovan međubankarski obračun. 

Manji ili jednak tekućem datumu 

2.4 

SettlementMethodCode 

Vrednost: CRLG 

2.6 

ClearinCycleld 

ID klirinškog ciklusa koji generiše Procesor i mora biti 
jedinstven na nivou dana. 

Struktura identifikatora: Datum+redni broj u toku dana 

2.7 

Trn 

ID swift poruke MT202 kojom je u RTGS sistemu 
realizovana neto pozicija učesnika u klirinškom krugu 
ClearingCycleID 

2.10 

Messageld 

MessagelD iz Header-a poruke u kojoj se nalazila realizovana 
instrukcija u kliringu 

Predstavlja jedinstveni identifikator poruke u kojoj se nalazila 
instrukcija 

2.11 

MessageName 

Može biti: 

pacs.003.001.01, za Collection instrukcije 
pacs.004.001.01, za Return/Refund instrukcija 
pacs.007.001.01, za Reversal instrukcija 

2.12 

CreationDate 

CreationDate iz Header-a poruke u kojoj se nalazila 
realiizovana instrukcija u kliringu 

2.13 

InstructingAgent.BICAgent 

InstructingAgent iz Header-a poruke u kojoj se nalazila 
realiizovana instrukcija u kliringu 

2.14 

InstructedAgent. BICAgent 

InstructedAgent iz Header-a poruke u kojoj se nalazila 
realiizovana instrukcija u kliringu 

2.15 

OriginalT ransactionld 

TransactionlD iz Collection, Return/Refund i Reversal 
instrukcije. 

Predstavlja ID instrukcije koja je realizovana u kliringu. 

2.16 

SettlementType 

- DEBIT za zaduženje računa učesnika 

- CREDIT za odobrenje računa učesnika 

2.17 

SettlementAmount. Amount 

Predstavlja iznos zaduženja ili odobrenja računa učesnika i to: 

- Settlement Amount, iz Collection instrukcija 

- ReturnSettlementAmount, iz Return/Refund instrukcija 

- Reversed SettlementAmount, iz Reversal instrukcija 

2.17 

SettlementAmount. 

CurrencyCode 

Vrednost: RSD 
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2.18 

DebtorAccount. 

IBANAccount 

Broj računa konačnog zaduženja i to: 

- DebtorAccount, iz Collection instrukcija 

- Creditor Account, iz Return/Refund instrukcija 

- Creditor Account, iz Reversal instrukcija 

2.19 

CreditorAccount. 

IBANAccount 

Broj računa konačnog odobrenja i to: 

- Creditor Account, iz Collection instrukcija 

- DebtorAccount, iz Return/Refund instrukcija 

- DebtorAccount, iz Reversal instrukcija 

2.21 

Purpose. Purport 

Purport (2.62) iz Collection instrukcije 

2.22 

Reason. ReasonCode 

ReasonCode (3.22 za Retum/Refund, odnosno 3.19 za 
Reversal instrukcije) 

2.23 

UnstructuredRemmitance 

UnstructuredRemmitance (2,82 za Collection, 3.79 za 
Return/Refund, odnosno 3.76 za Reversal instrukcije) 


Napomena: Nije potrebno vršiti dodatne kontrole sadržaja poruke, s obzirom da procesor kreira ove 
poruke na osnovu već kontrolisanih podataka iz instrukcija. 


PORUKA paos.006.001.01 COLLECTION QUERY 

Struktura: SerbianQuery 

• Zahtev za realizaciju upita u transakcije direktnog zaduženja koje se odnose na obračunski račun 
pošiljaoca poruke 

• Generiše je banka - učesnik u kliringu i dostavlja procesoru. 

• Poruka se sastoji od zaglavlja (Group Header) koje nosi zajedničke informacije upita i tela poruke 
(Transaction Information) koje sadrži uslove za upit u transakcije direktnog zaduženja koje su 
(ne)realizovane preko obračunskog računa učesnika u klirinškom ciklusu - podnosioca upita. 


• Struktura poruke: 


Index 

Kardin 

alnost 




Element poruke 

Tip 

Opis 

1.0 

M 1 

+ 

Header 

GroupHeaderl22 

Zaglavlje poruke 

1.1 

M 1 

+ 

+ 

Messageld 

Max35Text 

Jedinstveni identifikator 
poruke koji formira 

pošiljalac poruke 

1.2 

M 1 

+ 

+ 

CreationDate 

ISODateTime 

Datum kreiranja poruke 

1.3 

M 1 

+ 

+ 

InstructingAgent 

Finaneial 

Institution2 

Pošiljalac poruke 

1.3 

М 1 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija pošiljaoca 
poruke 

1.3 

М 1 

+ 

+ 

+ 

+ BICAgent 

BlCldentifier 

BIC pošiljaoca poruke 

1.4 

М 1 

+ 

+ 

InstructedAgent 

Financial 

Institution2 

Primalac poruke 

1.4 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

Identification4 

Identifikacija primaoca 
poruke 

1.4 

М 1 

+ 

+ 

+ 

+ BICAgent 

BlCldentifier 

BIC primaoca poruke 

2.0 

М 1 

+ 

Т ransactionlnfor ma tion 

Transaction 

InformationQuery 

Telo poruke za 

povlačenje poruke iii 
pojedinačne instrukcije 

2.1 

М 1 

+ 

+ 

Transactionld 

Max35Text 

Jedinstveni identifikator 
upita 

2.2 

0 0-1 

+ 

+ 

Messageldentification 

Message 

Identification 

Identifikacija poruke 

Upiti po proruci, odnosno: 

- Za konkretnu poruku 
(MessagelD) 

- Za poruke određenog 
tipa (MessageName) 

- Po datumu kreiranja 
poruke, za određeni dan 
(CreationDate) 

- U datom periodu 
realizacije 
(SettlementPeriod) 
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- Za konkretnog 
pošiljaoca 
(InstructingAgent) 

- Za konkretnog primaoca 
(InstructedAgent) 

2.3 

0 0-1 

+ 

+ 

+ 

Messageld 

Max35Text 

Jedinstveni identifikator 
poruke koji formira 

pošiljalac poruke 

2.4 

0 0-1 

+ 

+ 

+ 

MessageName 

Max35Text 

Naziv poruke 

(pacs.xxx.xxx.xx) 

2.5 

0 0-1 

+ 

+ 

+ 

CreationDate 

ISODateTime 

Datum kreiranja poruke 

2.6 

0 0-1 

+ 

+ 

+ 

SettlementPeriod 

Period 

Period međubankarskog 
obračuna 

2.6 

0 0-1 

+ 

+ 

+ 

+ 

SettlementDateFirst 

ISODate 

Datum od 

2.6 

0 0-1 

+ 

+ 

+ 

+ 

SettlementDateLast 

ISODate 

Datum do 

2.7 

0 0-1 

+ 

+ 

+ 

InstructingAgent 

Financial 

Institution2 

Pošiljalac poruke 

2.7 

0 0-1 

+ 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

Identification4 

Identifikacija pošiljaoca 
poruke 

2.7 

0 0-1 

+ 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC pošiljaoca poruke 

2.8 

0 0-1 

+ 

+ 

+ 

InstructedAgent 

Financial 

Institution2 

Primalac poruke 

2.8 

0 0-1 

+ 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

Identification4 

Identifikacija primaoca 
poruke 

2.8 

0 0-1 

+ 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC primaoca poruke 

2.9 

0 0-1 

+ 

+ 

OriginalT ransactionld 

Max35Text 

Id transakcije podnosioca 
Upiti po instrukciji za 
konkretnu instrukciju 

2.10 

0 0-1 

+ 

+ 

SettlementType 

SettlementType 

Vrsta transakcije u odnosu 
na račun Učesnika: 

CREDIT, DEBIT 

Upit u instrukcije kojima 
se zadužuje ili odobrava 
račun učesnika 

2.11 

0 0-1 

+ 

+ 

B etweenAmount 

MinMaxAmount 

Raspon iznosa transakcija 
Upit u transakcije koje su u 
datom rasponu iznosa 

2.11 

0 0-1 

+ 

+ 

+ 

MinAmount 

EuroMaxl5 

Amount 

Minimalni iznos 

transakcije 

2.11 

0 0-1 

+ 

+ 

+ 

+ 

Amount 

Decimal, 15,2 

Iznos transakcije u 

domaćoj valuti 

2.11 

0 0-1 

+ 

+ 

+ 

+ 

CurrencyCode 

EuroCurrencyCode 

Kod domaće valute 

2.11 

0 0-1 

+ 

+ 

+ 

MaxAmount 

EuroMaxl5 

Amount 

Maksimalni iznos 

transakcije 

2.11 

0 0-1 

+ 

+ 

+ 

+ 

Amount 

Decimal, 15,2 

Iznos transakcije u 

domaćoj valuti 

2.11 

0 0-1 

+ 

+ 

+ 

+ 

CurrencyCode 

EuroCurrencyCode 

Kod domaće valute 

2.12 

0 0-1 

+ 

+ 

DebtorAccount 

CashAccount8 

Broj računa zaduženja 

Upit u transakcije za datog 
dužnika (podnosilac upita 
predstavlja banku 

poverioca) 

2.12 

0 0-1 

+ 

+ 

+ 

Accountld 

Account 

Identification2 

Identifikacija broja računa 
zaduženja 

2.12 

0 0-1 

+ 

+ 

+ 

+ 

IBANAccount 

IBANldentifier 

IBAN broj računa 

zaduženja 

2.13 

0 0-1 

+ 

+ 

CreditorAccount 

CashAccount8 

Broj računa odobrenja 

Upit u transakcije za datog 
poverioca (podnosilac 

upita predstavlja banku 


Slobodan Babić \ Fakidtet organizacionih паика 


373 














































Doktorska disertacija: Model interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama 








dužnika) 

2.13 

0 0-1 

+ 

+ 

+ 

Accountld 

Account 

Identification2 

Identifikacija računa 

odobrenja 

2.13 

0 0-1 

+ 

+ 

+ 

+ 

IBANAccount 

IBANIdentifier 

IBAN broj računa 

odobrenja 


POSLOVNA PRAVILA 


Index 

Element poruke 

Poslovna pravila 

1.1 

Messageld 

U sistemu je jedinstven na nivou pošiljaoca. 

U slučaju standardizacije identifikatora u domaćem platnom 
prometu, kontrolu vršiti prema usvojenom standardu 

1.2 

CreationDate 

Jednak tekućem datumu 

1.3 

InstructingAgent. BICAgent 

Mora biti u evidenciji učesnika kliringa za direktna zaduženja 

1.4 

InstructedAgent. BICAgent 

BIC Procesora 

2.1 

Transactionld 

Predstavlja ID upita koji generiše banka koja je uputila upit 

U slučaju standardizacije identifikatora u domaćem platnom 
prometu, kontrolu vršiti prema usvojenom standardu 


Napomena: Nije potrebno vršiti dodatne kontrole sadržaja рошке, s obzirom da će rezultat upita (odgovor 
procesora) biti u skladu sa ,,kvalitetom“ podataka u upitu 


PORUKA paos.007.001.01 COLLECTION RESPONSE 
Struktura: SerbianResponse 

• Odgovor na upit 

• Generiše procesor i dostavlia banci koia ie podnela zahtev za realizaciiom upita (paos.006.001.01 
COLLECTION QUERY). 

• Poruka se sastoji od zaglavlja (Group Header) koje nosi zajedničke informacije upita i tela poruke 
(Transaction Information) koje sadrži transakcije direktnog zaduženja koje zadovoljavaju uslove 
postavljenog upita. 

• Struktura poruke: 


Index 

Kardin 

alnost 

Element poruke 

Tip 

Opis 

1.0 

M 1 

+ 

Header 

GroupHeaderl22 

Zaglavlje poruke 

1.1 

M 1 

+ 

+ 

Messageld 

Max35Text 

Jedinstveni 

identifikator poruke 

koji formira pošiljalac 
poruke 

1.2 

M 1 

+ 

+ 

CreationDate 

ISODateTime 

Datum kreiranja 

poruke 

1.3 

M 1 

+ 

+ 

InstructingAgent 

Financiai 

Institution2 

Pošiljalac poruke 

1.3 

М 1 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
ldentification4 

Identifikacija 

pošiljaocaporuke 

1.3 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC pošiljaoca poruke 

1.4 

М 1 

+ 

+ 

InstructedAgent 

Finaneiai 

Institution2 

Primalac poruke 

1.4 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

ldentification4 

Identifikacija primaoca 
poruke 

1.4 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC primaoca poruke 

2.0 

М 1 

+ 

Т ransactionlnformation 

T ransactionlnforma 

tionCollection 

Response 

Odgovor na postavljeni 
upit 

2.1 

М 1 

+ 

+ 

Transactionld 

Max35Text 

Jedinstveni 

identifikator odgovora 
na upit 

2.2 

М 1 

+ 

+ 

OriginalT ransactionld 

Max35Text 

Id transakcije 

podnosioca upita iz 
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originalne instrukcije 

2.3 

OO-n 

+ 

+ 

QueryResponse 

QueryAnd 

Response 

Odgovor na upit 

2.4 

M 1 

+ 

+ 

+ 

OriginalT ransactionlnfor 
mation 

OriginalT ransaction 
Information 

Identifikacija originalne 
poruke 

2.5 

M 1 

+ 

+ 

+ 

+ 

OriginalMessageld 

Max35Text 

Jedinstveni 

identifikator originalne 
poruke 

2.6 

M 1 

+ 

+ 

+ 

+ 

OriginalMessageName 

Max35Text 

Naziv originalne 

poruke 

(pacs.xxx.xxx.xx) 

2.7 

0 0-1 

+ 

+ 

+ 

+ 

OriginalCreationDate 

ISODateTime 

Datum kreiranja 

originalne poruke 

2.8 

M 1 

+ 

+ 

+ 

OriginalTransactionld 

Max35Text 

Id transakcije banke 
podnosioca instrukcije iz 
originalne instrukcije 

2.9 

М 1 

+ 

+ 

+ 

T ransactionStatus 

Transactionlndividua 

lStatus2Code 

Status transakcije iz 
internog šifarnika 

Procesora 

2.10 

М 1 

+ 

+ 

+ 

OriginalT ransactionlnfor 
mation 

Transaction 

Information3 

Telo poruke za 

instrukcije 

pacs.xxx.xxx.xx 


POSLOVNA PRAVILA 


Index 

Element poruke 

Poslovna pravila 

1.1 

Messageld 

U sistemu je jedinstven na nivou pošiljaoca. 

U slučaju standardizacije identifikatora u domaćem platnom 
prometu, kontrolu vršiti prema usvojenom standardu 

1.2 

CreationDate 

J ednak tekućem datumu 

1.3 

InstructingAgent. BICAgent 

BIC Procesora 

1.4 

InstructedAgent. BICAgent 

Mora biti u evidenciji učesnika kliringa za direktna zaduženja 

2.1 

Transactionld 

Predstavlja ID odgovora na upita koji generiše Procesor 

U slučaju standardizacije identifikatora u domaćem platnom 
prometu, kontrolu vršiti prema usvojenom standardu 

2.2 

OriginalTransactionld 

Transactionld iz Collection Query poruke 


Napomena: Nije potrebno vršiti dodatne kontrole sadržaja poruke, s obzirom da rezultat upita (odgovor 
procesora) predstavljaju već kontrolisani podaci iz instrukcija. 


PORUKA paos.008.001.01 CONFIRMATION 
Struktura: SerbianConfirmation 

• Informacija o neto poziciji Učesnika u ciklusu Kliringa 

• Generiše je procesor i dostavlja bankama učesnicima uklirinškom ciklusu. 

• Poruka se sastoji od zaglavlja (Group Header) koje nosi zajedničke informacije o neto poziciji i tela 
poruke (Transaction Information) koje sadrži neto poziciju banke. 


• Struktura poruke: 


Index 

Kardin 

alnost 

Element poruke 

Tip 

Opis 

1.0 

M 1 

+ 

Header 

GroupHeaderl22 

Zaglavlje poruke 

1.1 

M 1 

+ 

+ 

Messageld 

Max35Text 

Jedinstveni 

identifikator poruke 

koji formira pošiljalac 
poruke 

1.2 

M 1 

+ 

+ 

CreationDate 

ISODateTime 

Datum kreiranja 

poruke 

1.3 

M 1 

+ 

+ 

InstructingAgent 

FinancialInstitution2 

Pošiljalac poruke 

1.3 

М 1 

+ 

+ 

+ Agentld 

Financiallnstitution 

Identifikacija 
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ldentification4 

pošiljaoca poruke 

1.3 

M 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCIdentifier 

BIC pošiljaoca poruke 

1.4 

M 1 

+ 

+ 

InstructedAgent 

FinancialInstitution2 

Primalac poruke 

1.4 

M 1 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

ldentification4 

Identifikacija primaoca 
poruke 

1.4 

M 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC primaoca poruke 

2.0 

М 1 

+ 

Transactionlnformation 

Transaction 

Information 

Confirmation 

Telo poruke za 

dostavljanje 
infromacije o neto 

poziciji učesnika u 
kliringu 

2.1 

М 1 

+ 

+ 

SettlementDate 

ISODate 

Datum 

međubankarskog 

obračuna 

2.2 

М 1 

+ 

+ 

Settlementlnformation 

Settlement 

Information9 

Informacije o obračunu 

2.2 

М 1 

+ 

+ 

+ 

SettlementMethodCode 

SettlementMethod2 

Code 

Vrednost: CLRG 

2.3 

М 1 

+ 

+ 

ClearinCycleld 

Maxl6Text 

Identifikacija 
klirinškog ciklusa 

2.4 

М 1 

+ 

+ 

TRN 

Maxl6Text 

ldentifator swift poruke 
MT202 za realizaciju 
Neto pozicija učesnika u 
kliringu 

2.5 

М 1 

+ 

+ 

CreditType 

SettlementCredit 

Information 

Transakcije odobrenja 

2.5 

М 1 

+ 

+ 

+ 

SettlementAmount 

EuroMaxl 5Amount 

Iznos transakcija 

odobrenja 

2.5 

М 1 

+ 

+ 

+ 

+ 

Amount 

Decimal, 15,2 

Iznos transakcija 

odobrenja u domaćoj 
valuti 

2.5 

М 1 

+ 

+ 

+ 

+ 

CurrencyCode 

EuroCurrencyCode 

Kod domaće valute 

2.6 

М 1 

+ 

+ 

DebitType 

SettlementDebit 

Information 

Transakcije zaduženja 

2.6 

М 1 

+ 

+ 

+ 

SettlementAmount 

EuroMaxl 5Amount 

Iznos transakcija 

zaduženja 

2.6 

М 1 

+ 

+ 

+ 

+ 

Amount 

Decimal, 15,2 

Iznos transakcija 

zaduženja u domaćoj 
valuti 

2.6 

М 1 

+ 

+ 

+ 

+ 

CurrencyCode 

EuroC иггепсу Code 

Kod domaće valute 

2.7 

М 1 

+ 

+ 

SettlementType 

SettlementType 

Tip transakcije u odnosu 
na neto poziciju računa 
Učesnika u kliringu: 
CREDIT, DEBIT 

2.8 

М 1 

+ 

+ 

InterbankSettlementAmount 

EuroMaxl 5Amount 

Iznos transakcije u 

međubankarskom 

obračunu 

2.8 

М 1 

+ 

+ 

+ 

Amount 

Decimal, 15,2 

Iznos transakcije u 
domaćoj valuti 

2.8 

М 1 

+ 

+ 

+ 

CurrencyCode 

EuroCurrencyCode 

Kod domaće valute 


POSLOVNA PRAVILA 


Index 

Element poruke 

Poslovna pravila 

1.1 

Messageld 

U sistemu je jedinstven na nivou pošiljaoca. 

U slučaju standardizacije identifikatora u domaćem platnom 
prometu, kontrolu vršiti prema usvojenom standardu 

1.2 

CreationDate 

J ednak tekućem datumu 

1.3 

InstructingAgent.BICAgent 

BIC Procesora 
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1.4 

InstructedAgent. BICAgent 

Mora biti u evidenciji učesnika kliringa za direktna zaduženja 

2.1 

SettlementDate 

Datum obračuna. 

Mora biti manji ili jednak od tekućem datumu 

2.2 

SettlementMethodCode 

Vrednost:CLRG 

2.3 

ClearinCycleId 

Kontrola klirnškog ciklusa u evidenciji Procesora 

2.4 

TRN 

Kontrola identifikatora SWIFT poruke u evidenciji Procesora 

2.5 

CreditType. Amount 

Suma svih odobrenja obračunskog računa učesnika u kliringu 

2.5 

CreditType. CurrencyCode 

Vrednost: RSD 

2.6 

DebitType. Amount 

Suma svih zaduženja obračunskog računa učesnika u kliringu 

2.6 

DebitType. CurrencyCode 

Vrednost: RSD 

2.7 

SettlementType 

Vrednosti: 

- CREDIT, ukoliko je CreditType. Amount veći ili jednak od 
D eb itTyp e. Amo unt 

- DEBIT, ukoliko je CreditType. Amount manji od 
D eb i tTyp e. Amo unt 

2.8 

InterbankSettlementAmount. 

Amount 

Apsolutna vrednost razlike:CreditType. Amount- 

D ebitTyp e. Amo unt 

2.8 

InterbankSettlementAmount. 

CurrencyCode 

Vrednost: RSD 


PORUKA paos.009.001.01 LIMIT 

Struktura: SerbianLimit 

• Zahtev za postavljanje Limita zaduženja do koga banka može biti zadužena u klirinškom ciklusu 

• Generišu je banke učesnici u kliringu i dostavljaju procesoru. 

• Poruka se sastoji od zaglavlja (Group Header) koje nosi zajedničke informacije o limitu zaduženja i 


tela poruke (Transaction Information) koje sadrži Limit zaduženja. 
• Struktura poruke: _ 


Index 

Kardin 

alnost 

Element poruke 

Tip 

Opis 

1.0 

M 1 

+ 

Header 

GroupHeaderl22 

Zaglavlje poruke 

1.1 

M 1 

+ 

+ 

Messageld 

Max35Text 

Jedinstveni identifikator 

poruke koji formira 

pošiljalac poruke 

1.2 

M 1 

+ 

+ 

CreationDate 

ISODateTime 

Datum kreiranja poruke 

1.3 

M 1 

+ 

+ 

InstructingAgent 

Financiallnstitution2 

Pošiljalac poruke 

1.3 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

ldentification4 

Identifikacija pošiljaoca 

poruke 

1.3 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCIdentifier 

BIC pošiljaoca poruke 

1.4 

М 1 

+ 

+ 

InstructedAgent 

Financiallnstitution2 

Primalac poruke 

1.4 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

ldentification4 

Identifikacija primaoca 

poruke 

1.4 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC primaoca poruke 

2.0 

М 1 

+ 

Т ra nsactionlnfor mation 

Transaction 

InformationLimit 

Telo poruke za 

dostavljanje Limita 

zaduženja računa 

Učesnika u kliringu 

2.1 

М 1 

+ 

+ 

Account 

CashAccount8 

Broj računa učesnika u 
RTGS sistemu za učesnik 
postavlja Limit zaduženja 

2.1 

М 1 

+ 

+ 

+ 

Accountld 

Accountldentification2 

Identifikacija broja računa 

2.1 

М 1 

+ 

+ 

+ 

+ 

IBANAccount 

IBANldentifier 

IBAN broj računa 

2.2 

М 1 

+ 

+ 

LimitAmount 

EuroMaxl 5Amount 

Limit 

2.2 

М 1 

+ 

+ 

+ 

Amount 

Decimal, 15,2 

Iznos limita u domaćoj 
valuti 

2.2 

М 1 

+ 

+ 

+ 

CurrencyCode 

EuroCurrencyCode 

Kod domaće valute: RSD 
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POSLOVNA PRAVILA 


Index 

Element poruke 

Poslovna pravila 

1.1 

Messageld 

U sistemu je jedinstven na nivou pošiljaoca. 

U slučaju standardizacije identifikatora u domaćem platnom 
prometu, kontrolu vršiti prema usvojenom standardu 

1.2 

CreationDate 

J ednak tekućem datumu 

1.3 

InstructingAgent.BICAgent 

Mora biti u evidenciji učesnika kliringa za direktna zaduženja 

1.4 

InstructedAgent. BICAgent 

BIC Procesora 

2.1 

Account. IBANAccount 

Žiro račun učesnika u RTGS sistemu, evidentiran kod procesora 

2.2 

LimitAmount. Amount 

Veći ili jednak nuli 

2.2 

LimitAmount. 

CurrencyCode 

Vrednost: RSD 


PORUKA admi.002.001.01 administrativna poruka 

• Obaveštenje o odbijanju prethodno primljene рошке, koje procesorski sistem šalje pošiljaocu 
poruke i sadrži specifične informacije o razlozima odbijanja. 

• Generiše je procesor i dostavlja učesniku u kliringu - pošiljaocu poruke. 

• Poruka se sastoji od zaglavlja (Group Header) koje nosi zajedničke informacije i tela poruke (Rsn) 


koje sadrži specifične informacije o razlozima odbijanja. 
• Struktura poruke: _ 


Index 

Kardin 

alnost 

Element poruke 

Tip 

Opis 

1.0 

M 1 

+ 

Header 

GroupHeaderl22 

Zaglavlje poruke 

1.1 

M 1 

+ 

+ 

Messageld 

Max35Text 

Jedinstveni 

identifikator poruke 

koji formira pošiljalac 
poruke 

1.2 

M 1 

+ 

+ 

CreationDate 

ISODateTime 

Datum kreiranja poruke 

1.3 

M 1 

+ 

+ 

InstructingAgent 

FinanciaIInstitution2 

Pošiljalac poruke 

1.3 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

ldentification4 

Identifikacija 
pošiljaoca poruke 

1.3 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC pošiljaoca poruke 

1.4 

М 1 

+ 

+ 

InstructedAgent 

FinanciaIInstitution2 

Primalac poruke 

1.4 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

Identification4 

Identifikacija primaoca 
poruke 

1.4 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCIdentifier 

BIC primaoca poruke 

2.0 

М 1 

+ 

Rsn 

Rej ectionReason2 

Opis razloga odbijanja 

2.1 

М 1 

+ 

+ 

Ref 

Max35Text 

Referenca 

2.2 

М 1 

+ 

+ 

RjctgPtyRsn 

Max35Text 

Razlog odbijamja 
poruke 

2.3 

0 0- 
1 

+ 

+ 

RjctnDtTm 

ISODateTime 

Vreme i datum 
odbijanja poruke 

2.4 

0 0- 
1 

+ 

+ 

ErrLctn 

Max35Text 

Greška 

2.5 

0 0- 
1 

+ 

+ 

RsnDesc 

Max350Text 

Opis razloga 

2.6 

О 0- 
1 

+ 

+ 

AddtlData 

Max20000Text 

Dodatni podaci 


POSLOVNA PRAVILA 


Index 

Element poruke 

Poslovna pravila 

2.0 

Rsn 

Informacije o odbijanju poruke 

2.1 

Ref 

Referenca koja identifikuje poruku koja se odbija 

2.2 

RjctgPtyRsn 

Razlog odbijanja poruke, minimalna dužina 1, maksimalna 35 
karaktera 
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2.3 

RjctnDtTm 

Vreme i datum generisanja poruke za odbijanje 

2.4 

ErrLctn 

Mesto u poruci na kojem je konstatovana greška zbog koje se 
poruka odbija 

2.5 

RsnDesc 

Opis razloga odbijanja, maksimalno 350 karaktera 

2.6 

AddtlData 

Dodatno obrazloženje odbijanja, maksimalna 20.000 karaktera 


PORUKA admi.004.001.01 poruka za notiflkaciju 

• Obaveštenje o pojavi događaja u sistemu 

• Generiše je procesor i dostavlja učesnicima u kliringu. 

• Poruka se sastoji od zaglavlja (Group Header) koje nosi zajedničke informacije i tela poruke (Evtlnf) 


koje sadrži informaciju participantima o događaju koji su se pojavili u sistemu. 
• Struktura poruke: _ 


Index 

Kardin 

alnost 

Element poruke 

Tip 

Opis 

1.0 

M 1 

+ 

Header 

GroupHeaderl22 

Zaglavlje poruke 

1.1 

M 1 

+ 

+ 

Messageld 

Max35Text 

Jedinstveni identifikator 
poruke koji formira 
pošiljalac poruke 

1.2 

M 1 

+ 

+ 

CreationDate 

ISODateTime 

Datum kreiranja poruke 

1.3 

M 1 

+ 

+ 

InstructingAgent 

Financial 

Institution2 

Pošiljalac poruke 

1.3 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

ldentification4 

Identifikacija pošiljaoca 
poruke 

1.3 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC pošiljaoca poruke 

1.4 

М 1 

+ 

+ 

InstructedAgent 

Financial 

Institution2 

Primalac poruke 

1.4 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

ldentification4 

Identifikacija primaoca 
poruke 

1.4 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC primaoca poruke 

3.0 

М 1 

+ 

Evtlnf 

Eventl 

Informacija o 

događaju 

3.1 

М 1 

+ 

+ 

EvtCd 

Max4Alpha 

NumericText 

Defmisani kod 

događaja 

3.2 

0 0-1 

+ 

+ 

EvtParam 

Max35Text 

Parametri događaja 

3.3 

0 0-1 

+ 

+ 

EvtDesc 

Max350Text 

Opis događaja 

3.4 

0 0-1 

+ 

+ 

EvtTm 

ISODateTime 

Vreme događaja 


POSLOVNA PRAVILA 


Index 

Element poruke 

Poslovna pravila 

3.0 

Evtlnf 

Detaljne informacije o događaju u sistemu 

3.1 

EvtCd 

Kod događaja definisan od strane KIB-a u formatu [a-zA-Z0- 
9] {1,4} 

3.2 

EvtParam 

Parametri dodađaja definisani od strane KIB-a, maksimalno 35 
karaktera 

3.3 

EvtDesc 

Ops događaja, maksimalna 350 karaktera 

3.4 

EvtTm 

Datum i vreme generisanja poruke o događaju 


PORUKA MT202 

• Za realizaciju međubankarskog obračuna u RTGS sistemu 

• Generiše je procesor i dostavlja RTGS sistemu po završenom ciklusu Kliringa 

• U zavisnosti od neto pozicije učesnika u kliringu, realizuje naplatu odnosno plaćanje na račun 


Učesnika u kliringu 
• Struktura poruke: 


Polje 

Element poruke 

Kardinalnost 

113 

Poslovni prioritet 

M 1 

20 

Referenca pošiljoca 

M 1 

21 

Povezana referenca 

M 1 


Slobodan Babić \ Fakultet organizacionih паика 


379 

















































Doktorska disertacija: Model interoperabilnog elektronskogposlovanja platnih sistema zasnovanih na ontologijama 


32A 

Datum valute, šifra valute.i/nos 

M 1 

53 A 

/D/račun 

BIC 

M 1 

58A 

/C/račun 

BIC 

M 1 

72 

Slobodan element 

M 1 


POSLOVNA PRAVILA 


Index 

Element poruke 

Poslovna pravila 

113 

Poslovni prioritet 

U bloku 3, vrednost: „0011“ 

20 

Referenca pošiljoca 

Referenca Procesora 

21 

Povezana referenca 

Vrednost: „NONREF” 

32А 

Datum valute, šifra 

valute, 

iznos 

Datum valute (u formatu ggmmdd): datum realizacije obračuna po 
kliringu 

Šifra valute: RSD 

Iznos (u formatu sa dva decimalna mesta i zarez kao celobrojni 
separator): iznos obračunate neto pozicicije učesnika u kliringu 

53А 

/D/račun 

BIC 

• Za realizaciju negativne neto pozicije, račun i BIC učesnika sa 
negativnom neto pozicijom 

• Za realizaciju pozitivne neto pozicije, račun i BIC Procesora 

58А 

/C/račun 

BIC 

• Za realizaciju negativne neto pozicij, račun i BIC Procesora 

• Za realizaciju pozitivne neto pozicije, račun i BIC učesnika sa 
pozitivnom neto pozicijom 

72 

Slobodan element 

Struktura elmenta: 

:72:/BNF/PBZ- 

//PBO- 

//SIF-283-DirectDebit+identifikacija ciklusa Kliringa 


PORUKA mndt.001.001.01 MANDATE 
Struktura: SerbianMandateEvidence 

• Koristi se za evidentiranje i izmenu sadržaja Mandata. Generišu je i ispostavljaju Procesoru banke 
koje koriste dodatni servis vođenja Registra mandata 

• Ukoliko se koristi kao instrukcija za evidendtiranje Mandata, element Amendmentlndicator ima 
vrednost FALSE 

• Ukoliko se koristi kao instrukcija za izmenu sadržaja Mandata, element Amendmentlndicator ima 
vrednost TRUE, a element OrgMandateld vrednost identifikatora osnovnog mandata 


Index 

Kardin 

alnost 

Element poruke 

Tip 

Opis i poslovna 
pravila 

1.0 

M 1 

+ 

Header 

GroupHeaderl 

Zaglavlje poruke 

1.1 

M 1 

+ 

+ 

Messageld 

Max35Text 

Jedinstveni 

identifikator poruke 

koji formira pošiljalac 
poruke. 

1.2 

M 1 

+ 

+ 

CreationDate 

ISODateTime 

Datum kreiranja 

poruke. 

1.26 

M 1 

+ 

+ 

InstructingAgent 

FinanciaIInstitution2 

Pošiljalac poruke 

1.26 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

Identification4 

Identifikacija 
pošiljaoca poruke 

1.26 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC pošiljaoca poruke 

1.27 

М 1 

+ 

+ 

InstructedAgent 

FinanciaIInstitution2 

Primalac poruke 

1.27 

М 1 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija primaoca 
poruke 

1.27 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCIdentifier 

BIC primaoca poruke 

2.0 

М 1-n 

+ 

T ransactionlnformation 

Transaction 

Information3 

Telo poruke za 

evidentiranje 
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Mandata 

2.1 

M 1 

+ 

+ 

Transactionld 

Max35Text 

Jedinstveni Id 

transakcije podnosioca 
instrukcije. 

2.8 

M 1 

+ 

+ 

Mandatelnformation 

MandateInformation3 

Informacije o mandatu 

2.9 

0 0-1 

+ 

+ 

+ 

Contractld 

Max35Text 

Broj ugovora po kome je 
izdat mandat 

2.10 

M 1 

+ 

+ 

+ 

MandateType 

MandateType 

Information8 

Tip mandata 

2.11 

M 1 

+ 

+ 

+ 

+ 

SequenceType 

SequenceT уре 1 Code 

Vrednosti: RECR, 

ONEO 

2.22 

М 1 

+ 

+ 

+ 

Mandateld 

Max35Text 

Identifikacija mandata ili 
aneksa 

2.23 

М 1 

+ 

+ 

+ 

DateSignature 

ISODate 

Datum potpisivanja 

mandata ili aneksa 

2.24 

М 1 

+ 

+ 

+ 

Amendmentlndicator 

T rueF alselndicator 

Indikator aneksa 

(izmena mandata) 

2.25 

0 0-1 

+ 

+ 

+ 

Amendmentlnformation 

Amendmentlnformation 

Details4 

Informacije o osnovnom 
mandatu 

2.26 

0 0-1 

+ 

+ 

+ 

+ 

OrgMandateld 

Max35Text 

Identifikator osnovnog 
mandata 

2.43 

М 1 

+ 

+ 

Creditor 

PartyIdentificationl3 

Poverilac 

2.43 

М 1 

+ 

+ 

+ 

Creditorld 

Max35Text 

Id poverioca, matični 
broj ili Jmbg 

2.43 

М 1 

+ 

+ 

+ 

Name 

Max70Text 

Ime poverioca 

2.43 

0 0-1 

+ 

+ 

+ 

PostAddress 

PostalAddress4 

Poštanska adresa 

poverioca 

2.43 

0 0-2 

+ 

+ 

+ 

+ 

Address 

Max70Text 

Adresa poverioca 

2.43 

М 1 

+ 

+ 

+ 

+ 

CountryCode 

CountryCode 

Kod države poverioca 

2.44 

М 1 

+ 

+ 

CreditorAccount 

CashAccount8 

Broj računa poverioca 

2.44 

М 1 

+ 

+ 

+ 

Accountld 

Account 

Identification2 

Identifikacija računa 
poverioca 

2.44 

М 1 

+ 

+ 

+ 

+ 

IBANAccount 

IBANldentifier 

IBAN broj računa 
poverioca 

2.45 

М 1 

+ 

+ 

CreditorAgent 

FinancialInstitution2 

Banka poverioca 

2.45 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

Identification4 

Identifikacija banke 

poverioca 

2.43 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC banke poverioca 

2.57 

М 1 

+ 

+ 

Debtor 

PartyIdentificationl9 

Dužnika 

2.57 

М 1 

+ 

+ 

+ 

Debtorld 

Max35Text 

Id dužnika, matični broj 
ili Jmbg 

2.57 

М 1 

+ 

+ 

+ 

Name 

Max70Text 

Ime dužnika 

2.57 

0 0-1 

+ 

+ 

+ 

PostAddress 

PostalAddress4 

Poštanska adresa 

dužnika 

2.57 

0 0-2 

+ 

+ 

+ 

+ 

Address 

Max70Text 

Adresa dužnika 

2.57 

М 1 

+ 

+ 

+ 

+ 

CountryCode 

CountryCode 

Kod države dužnika 

2.58 

М 1 

+ 

+ 

DebtorAccount 

CashAccount8 

Broj računa dužnika 

2.58 

М 1 

+ 

+ 

+ 

Accountld 

Account 

Identification2 

Identifikacija računa 
dužnika 

2.58 

М 1 

+ 

+ 

+ 

+ 

IBANAccount 

IBANldentifier 

IBAN broj računa 
dužnika 

2.59 

М 1 

+ 

+ 

DebtorAgent 

FinancialInstitution2 

Banka dužnika 

2.59 

М 1 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija banke 

dužnika 

2.59 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC banke dužnika 

2.81 

0 0-1 

+ 

+ 

Remmitancelnformation 

Remittance 

Information3 

Informacije o 

plaćanju 

2.82 

0 0-n 

+ 

+ 

+ 

U nstructuredRemmitance 

Maxl40Text 

Nestruktuirane 
informacije o plaćanju 
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2.83 

M 1 

+ 

+ 

+ 

StructuredRemmitance 

StructuredRemittance 

Information6 

Struktuirane informacije 
o plaćanju 

2.84 

M 1 

+ 

+ 

+ 

+ 

FirstCollectionDate 

ISODate 

Datum kada može da 
bude realizovana prvo 
zaduženje 

2.84 

0 0-1 

+ 

+ 

+ 

+ 

FinalCollectionDate 

ISODate 

Datum do koga može 
da bude izvršavano 
poslednje zaduženje 

(Datum isteka 

mandata) 

2,85 

M 1 

+ 

+ 

+ 

+ 

Revocation 

Revocation 

Identificationl 

Opozivost Mandata 

2.85 

M 1 

+ 

+ 

+ 

+ 

+ 

Revocationlndicator 

TrueFalselndicator 

Indikator opozivosti 

Mandata 

2.85 

0 0-1 

+ 

+ 

+ 

+ 

+ 

Conditional 

Maxl40Text 

Uslovi opoziva Mandata 

2.86 

М 1 

+ 

+ 

+ 

+ 

NumberOfCollection 

Maxl5NumericText 

Maksimalni broj obavezž 
po mandatu 

2.87 

М 1 

+ 

+ 

+ 

+ 

TotalAmount 

EuroMax9Amount 

Ukupan iznos zaduženja 
po mandatu. 

2.87 

М 1 

+ 

+ 

+ 

+ 

+ 

Amount 

Decimal, 9,2 

Ukupan iznos plaćanja. 

2.87 

М 1 

+ 

+ 

+ 

+ 

+ 

CurrencyCode 

EuroCurrencyCode 

Kod valute (RSD) 

2.88 

0 0-1 

+ 

+ 

+ 

+ 

Frequency Metric 

FrequencyMetric 

Metrika dospeća 

2.88 

М 1 

+ 

+ 

+ 

+ 

+ 

Frequency Code 

FrequencyCode 

Kodirana metrika 

dospeća: 

DAIL, za dan, 

MNTFI, za mesec 
YEAR, za godinu 

2.88 

М 1 

+ 

+ 

+ 

+ 

+ 

Periodic 

Мах 15N umericT ext 

Periodika dospeća u 
datoj metrici 

2.89 

0 0-n 

+ 

+ 

+ 

+ 

FixedReqDate 

ISODate 

Fiksni datumi dospeća 
(DueDate) 

2.90 

0 0-1 

+ 

+ 

+ 

+ 

Tolerancy 

Tolerancy 

Period tolerancije 

dospeća u danima 

2.90 

М 1 

+ 

+ 

+ 

+ 

+ 

TolerancySign 

TolerancySign 

Kodirani znak perioda 
tolerancije: 

PLS, po dospeću 
(PLUS) 

MNS, pre dospeća 
(MINUS) 

BTH, pre i posle 
dospeća (BOTH) 

2.90 

М 1 

+ 

+ 

+ 

+ 

+ 

TolerancyValue 

Мах 15N umericT ext 

Broj dana tolerancije u 
dospeću 

2.91 

0 0-1 

+ 

+ 

+ 

+ 

DebitAmount 

EuroMax9Amount 

Maksimalni iznos u 
jednom nalogu 

zaduženja (collection) 

2.91 

М 1 

+ 

+ 

+ 

+ 

+ 

Amount 

Decimal, 9,2 

Iznos plaćanja. 

2.91 

М 1 

+ 

+ 

+ 

+ 

+ 

CurrencyCode 

EuroCurrencyCode 

Kod valute( RSD) 

2.92 

0 0-1 

+ 

+ 

+ 

+ 

Exchange 

Exchange 

Valutni uslovi plaćanja 

2.92 

М 1 

+ 

+ 

+ 

+ 

+ 

CurrencyCode 

CurrencyCode 

Kod valute plaćanja 

2.92 

М 1 

+ 

+ 

+ 

+ 

+ 

ExchangeRate 

BaseOnRate 

Kurs ugovorene valute: 
SEL - prodajni kurs 
МШ - srednji kurs 

BUY - kupovni kurs 

2.92 

М 1 

+ 

+ 

+ 

+ 

+ 

Exchange list 

BaseOnList 

Vrednosti : 

NBS - za kursnu listu 
Narodne banke 

BANK - za kursnu listu 
banke (nije osnov za 
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kontrolu Procesora) 

2.97 

0 0-1 

+ 

+ 

+ 

+ 

CreditorReference 

CreditorReference 

Informationl 

Referisanje poverioca na 
Identifikator dužnika 

2.97 

0 0-1 

+ 

+ 

+ 

+ 

+ 

ReferenceType 

C reditorReference 
Typel 

Referenca 

2.97 

0 0-1 

+ 

+ 

+ 

+ 

+ 

+ Purport 

Max35Text 

Poziv na broj dužnika 

2.105 

0 0-1 

+ 

+ 

+ 

+ 

AdditionalRemmitance 

Maxl40Text 

Dodatne informacije o 
plaćanju 


POSLOVNA PRAVILA 


Index 

Element poruke 

Poslovna pravila 

1.1 

Messageld 

U sistemu je jedinstven na nivou pošiljaoca. 

U slučaju standardizacije identifikatora u domaćem platnom 
prometu, kontrolu vršiti prema usvojenom standardu 

1.2 

CreationDate 

Manji ili jednak od tekućeg datuma 

1.26 

InstructingAgent. BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

1.27 

InstructedAgent. BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

2.1 

Transactionld 

Predstavlja ID instrukcije za evidentiranje ili izmenu Mandata 
koji generiše banka pošiljalac preko koga identifikuje transakciju 
Maksimalna dužina: Max32Text., osim u slučaju greške kada je 
Max35Text. 

U slučaju odbijanja instrukcije od strane Procesora zbog 
ustanovljene greške, drugom učesniku se dostavlja linstrukcije 
u kojoj Transactionld započinje sa ERR+originalni 

Transactionld 

2.11 

SequenceType 

Vrednosti: RECR, ONEO 

RECR - mandat s više dospeća 

ONEO - mandat sa jednim dospećem 

2.22 

Mandateld 

Jedinstveni identifikator mandata ili aneksa koji generiše Poverilac 
i obezbeđuje njegovu jedinstvenost (na nivou Poverioca). 

Struktura Mandateld: 

S Identifikacija mandata ili aneksa-Identifikacija pravnog 
lica koje je izdalo identifikaciju mandata ili aneksa i 
garantuje njegovu jedinstvenost na nvou Poverioca, ili 

S Idcntifikacija mandata ili aneksa (bez crtice) 

2.23 

DateSignature 

Manji ili jednak od datuma kreiranja poruke CreationDate. 

Za izmenu mandata (Amendmentlndicator=TRUE) mora biti veći 
ili jednak poslednjem važećem amandmanu osnovnog mandata 
(u statusu ACTV) 

2.24 

Amendmentlndicator 

TRUE - ukoliko se instrukcija podnosti po osnovu aneksa 
mandata 

FALSE - ukoliko se instrukcija podnosi po osnovu mandata 

2.26 

OrgMandateld 

Jedisntveni identifikator osnovnog mandata koji se menja. 

Mora postojati u Registru mandata. 

Poslednji važeći aneks ovog osnovnog mandata mora biti u 
aktivnom statusu ACTV 

2.43 

Creditor. Creditorld 

Struktura identifikatora u domaćem platnom prometu: 

Matični broj, dužine 8 - ukoliko se radi o Poveriocu pravnom 
licu 

JMBG, dužine 13 - ukoliko se radi o Poveriocu fizičkom licu koje 
obavlja delatnost 

Kontrola dužine. 

2.43 

Creditor. CountryCode 

Iz šifarnika država 

2.44 

CreditorAccount. 

IBANAccount 

Struktura broja računa u domaćem platnom prometu: 

DDKKBBBnnnnnnnnnnnnnKB 

Gde je: 
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DD - oznaka države (fiksna vrednost RS za Srbiju) 

KK - kontrolni broj po modelu 97 za ceo IBAN račun (fiksna 
vrednost 35 za Srbiju) 

BBB - šifra banke koja odgovara BIC-u banke poverioct 

(CreditorAgent) 

nnnnnnnnnnnnn - broj računa 

KB - kontrolni broj za broj računa bez oznake države (DD) i 
kontrolnog broja (KK) 

2.45 

CreditorAgent.BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

2.57 

Debtor.Debtorld 

Struktura identifikatora u domaćem platnom prometu: 

Matični broj, dužine 8 - ukoliko se radi o Dužniku pravnom licu 
JMBG, dužine 13 - ukoliko se radi o Dužniku fizičkom licu koje 
obavlja delatnost 

Kontrola dužine . 

2.57 

Debtor. CountryCode 

Iz šifarnika država 

2.58 

DebtorAccount. 

IBANAccount 

Struktura broja računa u domaćem platnom prometu: 

DDKKBBBnnnnnnnnnnnnnKB 

Gde je: 

DD - oznaka države (fiksna vrednost RS za Srbiju) 

KK - kontrolni broj po modelu 97 za ceo IBAN račun (fiksna 
vrednost 35 za Srbiju) 

BBB - šifra banke koja odgovara BIC-u banke dužnika 
(DebtorAgent) 

nnnnnnnnnnnnn - broj računa 

KB - kontrolni broj za broj računa bez oznake države (DD) i 
kontrolnog broja (KK) 

2.59 

DebtorAgent.BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

2.84 

FirstCollectionDate 

Datum kada može da bude realizovano prvo zaduženje 

Kontrola se vrši kod evidentiranja osnovnog mandata i to: ne 
može biti manji od datuma potpisa osnovnog mandata 
(DateSignature). 

2.84 

FinalCollectionDate 

Datum isteka Mandata - datum do koga može da bude 
realizovano poslednje zaduženje 

Ne može biti manji od datuma prvog zaduženja 
(FirstCollectionDate) niti manji od datuma potpisa mandata ili 
aneksa mandata (DateSignature) 

2.85 

Revocationlndicator 

Indikator opozivosti mandata: 

True - opoziv mandat 

False - neopoziv mandat 

2.85 

Revocation. Conditional 

Dodatni opis uslova opoziva 

2.86 

NumberOfCollection 

Maksimalni broj obaveza po mandatu 

Ako je dat, mora biti veći od nule i ne može biti manji od ukupmu 
broja zadatih fiksnih dospeća i broja dospeća po zadatoj metrici dc 
zadatog datuma poslednjeg zaduženja. 

Ukoliko se menja aneksom mandata, ne može biti manji od brojc 
realizovanih dospeća po mandatu u evidenciji Procesora 

2.87 

TotalAmount.Amount 

Ukupan iznos zaduženja po mandatu 

Ako je dat, mora biti veći od nule i veći od zadatog maksimalnog 
iznosa u jednom nalogu zaduženja (DebitAmount.Amount). 
Ukoliko se menja aneksom mandata, ne može biti manji oc 
ukupnog iznosa realizovanih dospeća po mandatu 

2.87 

T otal Amount. CurrencyCode 

Kod valute u kojoj je dat ukupan iznos zaduženja po mandatu. 
Mora biti RSD i jednak kao i kod valute maksimalnog iznosa po 
jednom zaduženju (DebitAmount. CurrencyCode). 

2.88 

Frequency Code 

Kodirana metrika dospeća: 

DAIL, za dan, 

MNTH, za mesec 

YEAR, za godinu 
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2.88 

Periodic 

Broj koji predstavlja periodiku dospeća u datoj metrici. 

Ako je dat mora biti veći od nule. 

2.89 

FixedReqDate 

Fiksni datumi dospeća (DueDate) 

2.90 

TolerancySign 

Kodirani znak perioda tolerancije: 

PLS, po dospeću (PLUS) 

MNS, pre dospeća (MINUS) 

BTH, pre i posle dospeća (BOTH) 

2.90 

TolerancyValue 

Broj dana tolerancije u dospeću 

Ako je dat mora biti veći od nule. 

2.91 

DebitAmount.Amount 

Maksimalni iznos u jednom nalogu zaduženja (collection) 

Ako je dat, mora biti veći od nule i ne sme biti veći od ukupnog 
iznosa zaduženja po mandatu (TotalAmount.Amount). 

2.91 

DebitAmount. CurrencyCode 

Kod valute maksimalnog iznosa po jednom zaduženju. 

Mora bitiRSD. 

2.92 

Exchange. C urrencyCode 

Kod ugovorene valute. 

Zadaje se ukoliko se razlikuje od koda valute plaćanja (RSD) i ne 
može se menjati aneksom (druga ugovorena valuta) 

Moguća eventualna kontrola da je kod valute iz šifarnika 
dozvoljenih valuta 

2.92 

Exchange.ExchangeRate 

Kurs za preračun iz ugovorene valute u valutu plaćanja (RSD): 

SEL - prodajni kurs 

MID - srednji kurs 

BUY - kupovni kurs 

2.92 

Exchange.Exchange list 

Oznaka kursne liste koja se pprimenjuje u preračunu iz ugovorene 
valute u valutu plaćanja (RSD): 

NBS - za kursnu listu Narodne banke (može biti osnov za kontrolu 
Collection-a od strane Procesora) 

BANK - za kursnu listu banke (nije osnov za kontrolu Collection- 
a od strane Procesora) 

2.97 

CreditorReference. Purport 

Identifikator na koji se referiše Poverilac pri ispostavljanju 
instrukcije direktnog zaduženja. Ovaj identifikator generiše 
Dužnik preko koga Dužnik identifikuje transakciju. 
Strukturapoziva na brojdužnika u domaćem platnom prometu: 
MMPPPPPPPPPPPPPPPPPPPP, gde je: 

MM - model poziva na broj sa vrednošću 97 ili „ „ 
PPPPPPPPPPPPPPPPPPPP - poziv na broj dužnika. 

Kontrola strukture ili vrednosti ,,NONPROVIDED“. 

2.105 

AdditionalRemmitance 

Druge struktuirane informacije dogovorene od strane Dužnika i 
Poverioca koje služe za dokumentovanje ispunjenosti uslova za 
realizaciju plaćanja navedenih u mandatu, a koje Procesor ne 
kontroliše 


PORUKA mndt.002.001.01 REMOVE MANDATE 
Struktura: SerbianMandateRemove 

• Koristi se za povlačenje Mandata. Generišu je i ispostavljaju Procesoru banke koje koriste dodatni 
servis vođenja Registra mandata 

• Element MandateStatus ima vrednost REMO 


Index 

Kardin 

alnost 

Element poruke 

Tip 

Opis i poslovna pravila 

1.0 

M 1 

+ 

Header 

GroupHeaderl 

Zaglavlje poruke 

1.1 

M 1 

+ 

+ 

Messageld 

Max35Text 

Jedinstveni identifikator 
poruke koji formira 
pošiljalac poruke. 

1.2 

M 1 

+ 

+ 

CreationDate 

ISODateTime 

Datum kreiranja poruke. 

1.26 

M 1 

+ 

+ 

InstructingAgent 

Financial 

Institution2 

Pošiljalac poruke 

1.26 

М 1 

+ 

+ 

+ Agentld 

F inanciallnstitution 
Identification4 

Identifikacija pošiljaoca 
poruke 
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1.26 

M 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC pošiljaoca poruke 

1.27 

M 1 

+ 

+ 

InstructedAgent 

Financiai 

Institution2 

Primalac poruke 

1.27 

M 1 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

Identification4 

Identifikacija primaoca 
poruke 

1.27 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCIdentifier 

BIC primaoca poruke 

2.0 

М 1-n 

+ 

Т ransactionlnformation 

Transaction 

Information3 

Telo poruke za 

evidentiranje Mandata 

2.1 

М 1 

+ 

+ 

Transactionld 

Max35Text 

Jedinstveni Id transakcije 
podnosioca instrukcije. 

2.8 

М 1 

+ 

+ 

Mandatelnformation 

Mandate 

Information3 

Informacije o mandatu 

2.9 

0 0-1 

+ 

+ 

+ 

Contractld 

Max35Text 

Broj ugovora po kome je 
izdat mandat 

2.10 

М 1 

+ 

+ 

+ 

MandateType 

MandateType 

Information8 

Tip mandata 

2.11 

М 1 

+ 

+ 

+ 

+ 

SequenceType 

SequenceT уре 1 Code 

Vrednosti: RECR, ONEO 

2.22 

М 1 

+ 

+ 

+ 

Mandateld 

Max35Text 

Identifikacija mandata 

2.23 

М 1 

+ 

+ 

+ 

DateSignature 

ISODate 

Datum potpisivanja 

mandata 

2.43 

М 1 

+ 

+ 

Creditor 

Party 

Identificationl3 

Poverilac 

2.43 

М 1 

+ 

+ 

+ 

Creditorld 

Max35Text 

Id poverioca, matični broj 
ili Jmbg 

2.43 

М 1 

+ 

+ 

+ 

Name 

Max70Text 

Ime poverioca 

2.43 

0 0-1 

+ 

+ 

+ 

PostAddress 

PostalAddress4 

Poštanska adresa 

poverioca 

2.43 

0 0-2 

+ 

+ 

+ 

+ 

Address 

Max70Text 

Adresa poverioca 

2.43 

М 1 

+ 

+ 

+ 

+ 

CountryCode 

CountryCode 

Kod države poverioca 

2.44 

М 1 

+ 

+ 

CreditorAccount 

CashAccount8 

Broj računa poverioca 

2.44 

М 1 

+ 

+ 

+ 

Accountld 

Account 

ldentification2 

Identifikacija računa 

poverioca 

2.44 

М 1 

+ 

+ 

+ 

+ 

IBANAccount 

IBANIdentifier 

IBAN broj računa 

poverioca 

2.45 

М 1 

+ 

+ 

CreditorAgent 

FinancialInstitution2 

Banka poverioca 

2.45 

М 1 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija banke 

poverioca 

2.43 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCIdentifier 

BIC banke poverioca 

2.57 

М 1 

+ 

+ 

Debtor 

Party 

Identificationl9 

Dužnika 

2.57 

М 1 

+ 

+ 

+ 

Debtorld 

Max35Text 

Id dužnika, matični broj ili 
Jmbg 

2.57 

М 1 

+ 

+ 

+ 

Name 

Max70Text 

Ime dužnika 

2.57 

0 0-1 

+ 

+ 

+ 

PostAddress 

PostalAddress4 

Poštanska adresa dužnika 

2.57 

0 0-2 

+ 

+ 

+ 

+ 

Address 

Max70Text 

Adresa dužnika 

2.57 

М 1 

+ 

+ 

+ 

+ 

CountryCode 

CountryCode 

Kod države dužnika 

2.58 

М 1 

+ 

+ 

DebtorAccount 

CashAccount8 

Broj računa dužnika 

2.58 

М 1 

+ 

+ 

+ 

Accountld 

Account 

ldentification2 

Identifikacija računa 

dužnika 

2.58 

М 1 

+ 

+ 

+ 

+ 

IBANAccount 

IBANIdentifier 

IBAN broj računa 

dužnika 

2.59 

М 1 

+ 

+ 

DebtorAgent 

FinancialInstitution2 

Banka dužnika 

2.59 

М 1 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija banke 

dužnika 

2.59 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCIdentifier 

BIC banke dužnika 

2.60 

М 1 

+ 

+ 

MandateStatus 

Mandatelndividual 

Status2Code 

Vrednosti: REMO 

2.105 

0 0-1 

+ 

+ 

AdditionalReasonlnformation 

Maxl05Text 

Dodatno obrazloženje za 
povlačenje mandata 
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POSLOVNA PRAVILA 


Index 

Element poruke 

Poslovna pravila 

1.1 

Messageld 

U sistemu je jedinstven na nivou pošiljaoca. 

U slučaju standardizacije identifikatora u domaćem platnom 
prometu, kontrolu vršiti prema usvojenom standardu 

1.2 

CreationDate 

Manji ili jednak od tekućeg datuma 

1.26 

InstructingAgent. BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

1.27 

InstructedAgent. BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

2.1 

Transactionld 

Predstavlja ID instrukcije za povlačenje Mandata koji generiše 
banka pošiljalac i preko koga identifikuje transakciju 

Maksimalna dužina: Max32Text., osim u slučaju greške kada je 
Max35Text. 

U slučaju odbijanja instrukcije od strane Procesora zbog 
ustanovljene greške, drugom učesniku se dostavlja linstrukcije u 
kojoj Transactionld započinje sa ERR+originalni Transactionld 

2.9 

Contractld 

Broj ugovora po kome je izdat mandat 

2.11 

SequenceType 

Vrednosti: RECR, ONEO 

RECR - mandat s više dospeća 

ONEO - mandat sa jednim dospećem 

2.22 

Mandateld 

Jedinstveni identifikator mandata koji se povlači. 

Pri povlačenju mandata mora biti identifikator osnovnog mandata 
(ne aneksa) koji postoji u Registru mandata, i poslednji aneks (ili 
osnovni mandata) mora biti aktivan (status ACTV) 

2.43 

Creditor.Creditorld 

Struktura identifikatora u domaćem platnom prometu: 

Matični broj, dužine 8 - ukoliko se radi o Poveriocu pravnom licu 
JMBG, dužine 13 - ukoliko se radi o Poveriocu fizičkom licu koje 
obavlja delatnost 

Kontrola dužine. 

2.43 

Creditor. CountryCode 

Iz šifamika država 

2.44 

CreditorAccount. 

IBANAccount 

Struktura broja računa u domaćem platnom prometu: 

DDKKBBBnnnnnnnnnnnnnKB 

Gde je: 

DD - oznaka države (fiksna vrednost RS za Srbiju) 

KK - kontrolni broj po modelu 97 za ceo IBAN račun (fiksna 
vrednost 35 za Srbiju) 

BBB - šifra banke koja odgovara BIC-u banke poveriocć 

(CreditorAgent) 

nnnnnnnnnnnnn - broj računa 

KB - kontrolni broj za broj računa bez oznake države (DD) i 
kontrolnog broja (KK) 

2.45 

CreditorAgent.BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

2.57 

Debtor.Debtorld 

Struktura identifikatora u domaćem platnom prometu: 

Matični broj, dužine 8 - ukoliko se radi o Dužniku pravnom licu 
JMBG, dužine 13 - ukoliko se radi o Dužniku fizičkom licu koje 
obavlja delatnost 

Kontrola dužine . 

2.57 

Debtor. CountryCode 

Iz šifarnika država 

2.58 

DebtorAccount. 

IBANAccount 

Struktura broja računa u domaćem platnom prometu: 

DDKKBBBnnnnnnnnnnnnnKB 

Gde je: 

DD - oznaka države (fiksna vrednost RS za Srbiju) 

KK - kontrolni broj po modelu 97 za ceo IBAN račun (fiksna 
vrednost 35 za Srbiju) 

BBB - šifra banke koja odgovara BIC-u banke đužnik: 
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(DebtorAgent) 

nnnnnnnnnnnnn - broj računa 

KB - kontrolni broj za broj računa bez oznake države (DD) i 
kontrolnog broja (KK) 

2.59 

DebtorAgent.BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

2.60 

MandateStatus 

Vrednosti: REMO, za povlačenje mandata 

2.105 

AdditionalReasonlnformation 

Tekstualni opis razloga povlačenja mandata 


PORUKA mndt.003.001.01 REJECT MANDATE 
Struktura: SerbianMandateReject 

• Koristi se za odbijanje instrukcija za evidentiranje, izmenu i povlačenje Mandata, pri čemu element 
OriginalMessageName ima vrednost tipa instrukcije koja se odbija (mndt.001.001.01 ili 
mndt.002.001.01) 


• Generišu je i ispostavljaju banke koje koriste dodatni servis vođenja Registra mandata, odnosno 
Procesor na osnovu izvršenih kontrola. 


Index 

Kardin 

alnost 

Element poruke 

Tip 

Opis i poslovna 
pravila 

1.0 

M 1 

+ 

Header 

GroupHeader2 

Zaglavlje poruke 

1.1 

M 1 

+ 

+ 

Messageld 

Max35Text 

Jedinstveni 
identifikator poruke 
koji fonnira 

pošiljalac poruke 

1.2 

M 1 

+ 

+ 

CreationDate 

ISODateTime 

Datum kreiranja 

poruke 

1.7 

M 1 

+ 

+ 

InstructingAgent 

FinancialInstitution2 

Pošiljalac poruke 

1.7 

М 1 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija 
pošiljaoca poruke 

1.7 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC pošiljaoca 

poruke 

1.8 

М 1 

+ 

+ 

InstructedAgent 

FinancialInstitution2 

Primalac poruke 

1.8 

М 1 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija 
primaoca poruke 

1.8 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC primaoca poruke 

2.0 

М 1-n 

+ 

Transactionlnformation 

T ra nsactionlnfor mation 

Telo poruke 

instrukcije 

odbijanja(Reject) 

2.1 

М 1 

+ 

+ 

Transactionld 

Max35Text 

Jedinstveni Id 

transakcije 
podnosioca 
instrukcije 

2.2 

М 1 

+ 

+ 

OriginalT ransactionlnformati 
on 

OriginalTransactionlnfo 

rmation 

Identifikacija 
originalne poruke 

2.3 

М 1 

+ 

+ 

+ 

OriginalMessageld 

Max35Text 

Jedinstveni 
identifikator 
originalne poruke 

2.4 

М 1 

+ 

+ 

+ 

OriginalMessageN ame 

Max35Text 

Naziv originalne 

poruke 

(mndt. ххх . ххх . хх) . 

2.6 

М 1 

+ 

+ 

OriginalT ransactionld 

Max35Text 

Id originalne 

instrukcije 

2.7 

М 1 

+ 

+ 

TransactionStatus 

T ransactionlndividual 
Status2Code 

Vrednost: RJCT 

2.8 

М 1 

+ 

+ 

Mandatelnformation 

MandateInformation3 

Informacije o 

mandatu 

2.9 

0 0-1 

+ 

+ 

+ 

Contractld 

Max35Text 

Broj ugovora po kome 
je izdat 

2.10 

М 1 

+ 

+ 

+ 

MandateType 

MandateType 

Information8 

Tip mandata 
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2.11 

M 1 

+ 

+ 

+ 

+ 

SequenceType 

SequenceT уре 1 Code 

Vrednosti: RECR, 

ONEO 

2.22 

M 1 

+ 

+ 

+ 

Mandateld 

Max35Text 

Identifikacija mandata 

2.23 

M 1 

+ 

+ 

+ 

DateSignature 

ISODate 

Datum potpisivanja 
mandata 

2.24 

M 1 

+ 

+ 

+ 

Amendmentlndicator 

T rueF alselndicator 

Indikator aneksa 

(izmena mandata) 

2.25 

0 0-1 

+ 

+ 

+ 

Amendmentlnformation 

Amendmentlnformation 

Details4 

Informacije o 

osnovnom mandatu 

2.26 

0 0-1 

+ 

+ 

+ 

+ 

OrgMandateld 

Max35Text 

Identifikator 
osnovnog mandata 

2.43 

М 1 

+ 

+ 

Creditor 

PartyIdentificationl3 

Poverilac 

2.43 

М 1 

+ 

+ 

+ 

Creditorld 

Max35Text 

Id poverioca, matični 
broj ili Jmbg 

2.43 

М 1 

+ 

+ 

+ 

Name 

Max70Text 

Ime poverioca 

2.43 

0 0-1 

+ 

+ 

+ 

PostAddress 

PostalAddress4 

Poštanska adresa 

poverioca 

2.43 

0 0-2 

+ 

+ 

+ 

f 

Address 

Max70Text 

Adresa poverioca 

2.43 

М 1 

+ 

+ 

+ 

f 

CountryCode 

CountryCode 

Kod države poverioca 

2.44 

М 1 

+ 

+ 

CreditorAccount 

CashAccount8 

Broj računa 

poverioca 

2.44 

М 1 

+ 

+ 

+ 

Accountld 

AccountIdentification2 

Identifikacija računa 
poverioca 

2.44 

М 1 

+ 

+ 

+ 

+ 

IBANAccount 

IBANIdentifier 

IBAN broj računa 
poverioca 

2.45 

М 1 

+ 

+ 

CreditorAgent 

F inanciallnstitution2 

Banka poverioca 

2.45 

М 1 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija banke 
poverioca 

2.43 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC banke poverioca 

2.57 

М 1 

+ 

+ 

Debtor 

PartyIdentificationl9 

Dužnika 

2.57 

М 1 

+ 

+ 

+ 

Debtorld 

Max35Text 

Id dužnika, matični 
broj ili Jmbg 

2.57 

М 1 

+ 

+ 

+ 

Name 

Max70Text 

Ime dužnika 

2.57 

0 0-1 

+ 

+ 

+ 

PostAddress 

PostalAddress4 

Poštanska adresa 

dužnika 

2.57 

0 0-2 

+ 

+ 

+ 

+ 

Address 

Max70Text 

Adresa dužnika 

2.57 

М 1 

+ 

+ 

+ 

+ 

CountryCode 

CountryCode 

Kod države dužnika 

2.58 

М 1 

+ 

+ 

DebtorAccount 

CashAccount8 

Broj računa dužnika 

2.58 

М 1 

+ 

+ 

+ 

Accountld 

AccountIdentification2 

Identifikacija računa 
dužnika 

2.58 

М 1 

+ 

+ 

+ 

+ 

IBANAccount 

IBANIdentifier 

IBAN broj računa 
dužnika 

2.59 

М 1 

+ 

+ 

DebtorAgent 

Financiallnstitution2 

Banka dužnika 

2.59 

М 1 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija banke 
dužnika 

2.59 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC banke dužnika 

2.70 

М 1 

+ 

+ 

StatusReasonlnformation 

StatusReason 

Information4 

Informacije o 

raziozima odbijanja 
instrukcije 

2.71 

М 1 

+ 

+ 

+ 

StatusOriginator 

PartyIdentification 14 

Identifikacija 
inicijatora odbijanja 

instrukcije- banka, 

ugovorna strana 

2.72 

М 1 

+ 

+ 

+ 

+ 

Originatorld 

Financiallnstitution3 

Identifikacija banke 
inicijatora odbijanja 
instrukcije 

2.72 

М 1 

+ 

+ 

+ 

+ 

+ 

Originator 

Financiallnstitution 

Identification4 

Identifikacija banke 
inicijatora odbijanja 
instrukcije 
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2.72 

M 1 

+ 

+ 

+ 

+ 

+ 

+ 

BlCOriginator 

BlCldentifier 

BIC banke, 

inicijatora odbijanja 
instrukcije 

2.73 

M 1 

+ 

+ 

+ 

+ 

OriginatorName 

Max35Text 

Naziv ugovorne strane 
koja odbija instrukciju 

2.90 

M 1 

+ 

+ 

+ 

StatusReason 

ReturnReason3 C hoice 

Kodirani razlog 

odbijanja instrukcije 

2.91 

M 1 

+ 

+ 

+ 

+ 

StatusCode 

T ransactionReturn 
Reason5Code 

Kod razloga odbijanja 
instrukcije 

2.105 

0 0-1 

+ 

+ 

+ 

AdditionalReasonlnformat 

ion 

Maxl05Text 

Dodatno obrazloženje 
za odbijanje 

instrukcije. 


Specifikacija ISO kodova za Reject transakcije: 


ISO 

kod 

Opis 

ACOl 

Pogrešan broj računa 

AC04 

Račun zatvoren 

AC06 

Račun blokiran 

AG01 

Transakcija 

zabranjena 

AG02 

Pogrešan kod banke 

AM01 

Nula iznos 

AM02 

Nedopušten račun 

AM03 

Pogrešna valuta 

AM04 

Nedovoljno sredstava 

AM05 

Dupliran nalog 

AM06 

Premali iznos 

AM07 

Blokiran iznos 

AM09 

Pogrešan iznos 

AM10 

Pogrešna kontrolna 
suma 

BE01 

Nesaglasan krajnji 

korisnik 

BE04 

Pogrešna adresa 

poverioca 

BE05 

Neprepoznat 

poverilac 

BE06 

Neprepoznat dužnik 


ISO 

kod 

Opis 

BE07 

Pogrešna adresa dužnika 

DT01 

Pogrešan datum 

ED01 

Ne postoji korespodentna banka 

ED03 

Traženo stanje 

MD01 

Nema validnog mandata 

MD02 

Pogrešne informacije o mandatu 

MD03 

Pogrešan format podatka o razlozima 

MD04 

Pogrešan format podataka za indikatore 

MD06 

Dužnik je podneo Refunda zahtev 

MD07 

Dužnik je umro 

MS02 

Nije naveden razlog od strane dužnika 

MS03 

Nije naveden razlog od strane banke 

NARR 

Opisno 

RC01 

Pogrešan identifikator banke 

RFOl 

Referenca transakcije nije jedinstvena 

TM01 

Cutt off time (istek vremena) 

ED05 

Greška u obračunu 

RR01 

Razlozi regulatora (procesora) 


POSLOVNA PRAVILA 


Index 

Element poruke 

Poslovna pravila 

1.1 

Messageld 

U sistemu je jedinstven na nivou pošiljaoca. U slučaju 
standardizacije identifikatora u domaćem platnom prometu, 
kontrolu vršiti prema usvojenom standardu 

1.2 

CreationDate 

Manji ili jednak od tekućeg datume 

1.7 

InstructingAgent. BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

1.8 

InstructedAgent. BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

2.1 

Transactionld 

Predstavlja ID Reject instrukcije. 
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U slučaju standardizacije identifikatora u domaćem platnom 
prometu, kontrolu vršiti prema usvojenom standardu 

2.3 

OriginalMessageld 

Jedinstveni identifikator originalne poruke 

2.4 

OriginalMessageName 

Naziv originalne poruke: 

Vrednosti: mndt.001.001.01 i mndt.002.001.01 

2.6 

OriginalT ransactionld 

Transactionld iz originalne instrukcije koja se odbija. 

Kontrola postojanja instrukcije u evidenciji procesora za 
navedeni OriginalMessageName, OriginalMessageld i 

OriginalT ransactionld 

2.7 

TransactionStatus 

Vrednost: RJCT 

2.9 

Contractld 

Broj ugovora po kome je izdat mandat 

Kontrola vrednosti koja mora biti jednaka u originalnoj 
instrukciji koja se odbija 

2.11 

SequenceType 

Vrednosti: RECR, ONEO 

RECR - mandat s više dospeća 

ONEO - mandat sa jednim dospećem 

2.22 

Mandateld 

Jedinstveni identifikator mandata ili amandmana na koji se odnosi 
instrukcija koja se odbija. 

Kontrola vrednosti koja mora biti jednaka u originalnoj instrukciji 
koja se odbija. 

2.43 

Creditor.Creditorld 

Struktura identifikatora u domaćem platnom prometu: 

Matični broj, dužine 8 - ukoliko se radi o Poveriocu pravnom 
licu 

JMBG, dužine 13 - ukoliko se radi o Poveriocu fizičkom licu 
koje obavlja delatnost 

Kontrola dužine. 

2.43 

Creditor. CountryCode 

Iz šifarnika država 

2.44 

CreditorAccount. 

IBANAccount 

Struktura broja računa u domaćem platnom prometu: 

DDKKBBBnnnnnnnnnnnnnKB 

Gde je: 

DD - oznaka države (fiksna vrednost RS za Srbiju) 

KK - kontrolni broj po modelu 97 za ceo IBAN račun (fiksna 
vrednost 35 za Srbiju) 

BBB - šifra banke koja odgovara BIC-u banke poveriocž 

(CreditorAgent) 

nnnnnnnnnnnnn - broj računa 

KB - kontrolni broj za broj računa bez oznake države (DD) i 
kontrolnog broja (KK) 

2.45 

CreditorAgent.BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

2.57 

Debtor.Debtorld 

Struktura identifikatora u domaćem platnom prometu: 

Matični broj, dužine 8 - ukoliko se radi o Dužniku pravnom licu 
JMBG, dužine 13 - ukoliko se radi o Dužniku fizičkom licu koje 
obavlja delatnost 

Kontrola dužine . 

2.57 

Debtor. CountryCode 

Iz šifarnika država 

2.58 

DebtorAccount. 

IBANAccount 

Struktura broja računa u domaćem platnom prometu: 

DDKKBBBnnnnnnnnnnnnnKB 

Gde je: 

DD - oznaka države (fiksna vrednost RS za Srbiju) 

KK - kontrolni broj po modelu 97 za ceo IBAN račun (fiksna 
vrednost 35 za Srbiju) 

BBB - šifra banke koja odgovara BIC-u banke dužnikć 
(DebtorAgent) 

nnnnnnnnnnnnn - broj računa 

KB - kontrolni broj za broj računa bez oznake države (DD) i 
kontrolnog broja (KK) 

2.59 

DebtorAgent.BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

2.72 

StatusOriginator. 

Inicijatori odbijanja mogu biti Banka Poverioca, Banka Dužnika 
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BlCOriginator 

ili Procesor, koji se identifikuju BlC-om i koji mora biti u 
evidenciji aktivnih učesnika kliringa za direktna zaduženja. 
(Inicijatori mogu biti i Dužnik ili Poverilac, koji se identifikuju 
svojim nazivom, ali se ne vrši kontrola od strane Procesora) 

2.91 

StatusReason. StatusCode 

Kontrola koda razloga odbijanja u šifarniku kodova odbijanja 

2.105 

AdditionalReasonlnformation 

Ukoliko šifrirani kod razloga odbijanja ne objašnjava dovoljno 
razloge odbijanja, može se zadati i njegov tekstualni opis. 


PORUKA mndt.004.001.01 ACCEPT MANDATE 
Struktura: SerbianMandateAccept 

• Koristi se za eksplicitno prihvatanje instrukcija za evidentiranje, izmenu i povlačenje Mandata 

• Element OriginalMessageName ima vrednost tipa instrukcije koja se prihvata (mndt.001.001.01 ili 
mndt.002.001.01) 

• Generišu je i ispostavljaju banke koje koriste dodatni servis vođenja Registra mandata, odnosno 
Procesor na osnovu izvršenih kontrola. 


Index 

Kardin 

alnost 

Element poruke 

Tip 

Opis i poslovna 
pravila 

1.0 

M 1 

+ 

Header 

GroupHeader2 

Zaglavlje poruke 

1.1 

M 1 

+ 

+ 

Messageld 

Max35Text 

Jedinstveni identifikator 
poruke koji formira 
pošiljalac poruke 

1.2 

M 1 

+ 

+ 

CreationDate 

ISODateTime 

Datum kreiranja poruke 

1.7 

M 1 

+ 

+ 

InstructingAgent 

Financial 

Institution2 

Pošiljalac poruke 

1.7 

М 1 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija pošiljaoca 
poruke 

1.7 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC pošiljaoca poruke 

1.8 

М 1 

+ 

+ 

InstructedAgent 

Financial 

Institution2 

Primalac poruke 

1.8 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

Identification4 

Identifikacija primaoca 
poruke 

1.8 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCIdentifier 

BIC primaoca poruke 

2.0 

М 1-n 

+ 

Transactionlnformation 

Transaction 

Information 

Telo poruke 

instrukcije 
prihvatanja (Accept) 

2.1 

М 1 

+ 

+ 

Transactionld 

Max35Text 

Jedinstveni Id 

transakcije podnosioca 
instrukcije 

2.2 

М 1 

+ 

+ 

OriginalTransactionlnformation 

OriginalT ransaction 
Information 

Identifikacija originalne 
poruke 

2.3 

М 1 

+ 

+ 

+ 

OriginalMessageld 

Max35Text 

Jedinstveni identifikator 
originalne poruke 

2.4 

М 1 

+ 

+ 

+ 

OriginalMessageName 

Max35Text 

Naziv originalne poruke 
(mndt. ххх. ххх. хх) . 

2.6 

М 1 

+ 

+ 

OriginalTransactionld 

Max35Text 

Id originalne instrukcije 

2.7 

М 1 

+ 

+ 

TransactionStatus 

Transactionlndividual 

Status2Code 

Vrednost: ACPT 

2.8 

М 1 

+ 

+ 

Mandatelnformation 

Mandate 

Information3 

Informacije o mandatu 

2.9 

0 0-1 

+ 

+ 

+ 

Contractld 

Max35Text 

Broj ugovora po kome je 
izdat mandat 

2.10 

М 1 

+ 

+ 

+ 

MandateType 

MandateType 

Information8 

Tip mandata 

2.11 

М 1 

+ 

+ 

+ 

+ 

SequenceType 

SequenceT уре 1 Code 

Vrednosti: RECR, 

ONEO 

2.22 

М 1 

+ 

+ 

+ 

Mandateld 

Max35Text 

ldentifikacija mandata 

2.23 

М 1 

+ 

+ 

+ 

DateSignature 

ISODate 

Datum potpisivanja 

mandata 
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2.24 

M 1 

+ 

+ 

+ 

Amendmentlndicator 

T rueF alselndicator 

Indikator aneksa 

(izmena mandata) 

2.25 

0 0-1 

+ 

+ 

+ 

Amendmentlnformation 

Amendment 

InformationDetails4 

Informacije o osnovnom 
mandatu 

2.26 

0 0-1 

+ 

+ 

+ 

+ 

OrgMandateld 

Max35Text 

Identifikator osnovnog 
mandata 

2.43 

M 1 

+ 

+ 

Creditor 

Party 

Identificationl3 

Poverilac 

2.43 

M 1 

+ 

+ 

+ 

Creditorld 

Max35Text 

Id poverioca, matični 
broj ili Jmbg 

2.43 

M 1 

+ 

+ 

+ 

Name 

Max70Text 

Ime poverioca 

2.43 

0 0-1 

+ 

+ 

+ 

PostAddress 

PostalAddress4 

Poštanska adresa 

poverioca 

2.43 

0 0-2 

+ 

+ 

+ ■ 


Address 

Max70Text 

Adresa poverioca 

2.43 

М 1 

+ 

+ 

+ 


CountryCode 

CountryCode 

Kod države poverioca 

2.44 

М 1 

+ 

+ 

CreditorAccount 

CashAccount8 

Broj računa poverioca 

2.44 

М 1 

+ 

+ 

+ 

Accountld 

Account 

Identification2 

Identifikacija računa 
poverioca 

2.44 

М 1 

+ 

+ 

+ 

+ 

IBANAccount 

IBANldentifier 

IBAN broj računa 
poverioca 

2.45 

М 1 

+ 

+ 

CreditorAgent 

FinancialInstitution2 

Banka poverioca 

2.45 

М 1 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija banke 

poverioca 

2.43 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC banke poverioca 

2.57 

М 1 

+ 

+ 

Debtor 

Party 

IdentifIcationl9 

Dužnika 

2.57 

М 1 

+ 

+ 

+ 

Debtorld 

Max35Text 

Id dužnika, matični broj 
ili Jmbg 

2.57 

М 1 

+ 

+ 

+ 

Name 

Max70Text 

Ime dužnika 

2.57 

0 0-1 

+ 

+ 

+ 

PostAddress 

PostalAddress4 

Poštanska adresa 

dužnika 

2.57 

0 0-2 

+ 

+ 

+ 

+ 

Address 

Max70Text 

Adresa dužnika 

2.57 

М 1 

+ 

+ 

+ 

+ 

CountryCode 

CountryCode 

Kod države dužnika 

2.58 

М 1 

+ 

+ 

DebtorAccount 

CashAccount8 

Broj računa dužnika 

2.58 

М 1 

+ 

+ 

+ 

Accountld 

Account 

ldentification2 

Identifikacija računa 

dužnika 

2.58 

М 1 

+ 

+ 

+ 

+ 

IBANAccount 

IBANldentifier 

IBAN broj računa 
dužnika 

2.59 

М 1 

+ 

+ 

DebtorAgent 

FinancialInstitution2 

Banka dužnika 

2.59 

М 1 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija banke 

dužnika 

2.59 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC banke dužnika 

2.70 

М 1 

+ 

+ 

StatusReasonlnformation 

StatusReasonlnfor 

mation4 

Informacije o 

razlozima prihvatanja 

2.71 

М 1 

+ 

+ 

+ 

StatusOriginator 

Party 

ldentificationl4 

Identifikacija inicijatora 
prihvatanja instrukcije 
(banke i ugovorne strane) 

2.72 

М 1 

+ 

+ 

+ 

+ 

Originatorld 

FinancialInstitution3 

Identifikacija banke 

inicijatora prihvatanja 
instrukcije 

2.72 

М 1 

+ 

+ 

+ 

+ 

+ 

Originator 

F inanciallnstitution 
Identification4 

Identifikacija banke 

inicijatora prihvatanja 
instrukcije 

2.72 

М 1 

+ 

+ 

+ 

+ 

+ 

+ BlCOriginator 

BlCldentifier 

BIC banke, inicijatora 
prihvatanja instrukcije 

2.73 

М 1 

+ 

+ 

+ 

+ 

OriginatorName 

Max35Text 

Naziv ugovorne strane 
koja prihvata instrukciju 

2.105 

0 0-1 

+ 

+ 

+ 

AdditionalReasonlnformati 

on 

Maxl05Text 

Dodatno obrazloženje 
za prihvanje instrukcije. 
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POSLOVNA PRAVILA 


Index 

Element poruke 

Poslovna pravila 

1.1 

Messageld 

U sistemu je jedinstven na nivou pošiljaoca. 

U slučaju standardizacije identifikatora u domaćem platnom 
prometu, kontrolu vršiti prema usvojenom standardu 

1.2 

CreationDate 

Manji ili jednak od tekućeg datume 

1.7 

InstructingAgent. BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

1.8 

InstructedAgent. BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

2.1 

Transactionld 

Predstavlja ID Reject instrukcije. 

U slučaju standardizacije identifikatora u domaćem platnom 
prometu, kontrolu vršiti prema usvojenom standardu 

2.3 

OriginalMessageld 

Jedinstveni identifikator originalne poruke 

2.4 

OriginalMessageName 

Naziv originalne poruke: 

Vrednosti: mndt.001.001.01 i mndt.002.001.01 

2.6 

OriginalT ransactionld 

Transactionld iz originalne instrukcije koja se prihvata. 

Kontrola postojanja instrukcije u evidenciji procesora za 
navedeni OriginalMessageName, OriginalMessageld i 

OriginalT ransactionld 

2.7 

TransactionStatus 

Vrednost: ACPT 

2.9 

Contractld 

Broj ugovora po kome je izdat mandat 

Kontrola vrednosti koja mora biti jednaka u originalnoj 
instrukciji koja se prihvata 

2.11 

SequenceType 

Vrednosti: RECR, ONEO 

RECR - mandat s više dospeća 

ONEO - mandat sa jednim dospećem 

2.22 

Mandateld 

Jedinstveni identifikator mandata na koji se odnosi instrukcija 
koja se prihvata. 

Kontrola vrednosti koja mora biti jednaka u originalnoj instrukciji 
koja se prihvata 

2.43 

Creditor.Creditorld 

Struktura identifikatora u domaćem platnom prometu: 

Matični broj, dužine 8 - ukoliko se radi o Poveriocu pravnom 
licu 

JMBG, dužine 13 - ukoliko se radi o Poveriocu fizičkom licu 
koje obavlja delatnost 

Kontrola dužine. 

2.43 

Creditor. CountryCode 

Iz šifarnika država 

2.44 

CreditorAccount. 

IBANAccount 

Struktura broja računa u domaćem platnom prometu: 

DDKKBBBnnnnnnnnnnnnnKB 

Gde je: 

DD - oznaka države (fiksna vrednost RS za Srbiju) 

KK - kontrolni broj po modelu 97 za ceo IBAN račun (fiksna 
vrednost 35 za Srbiju) 

BBB - šifra banke koja odgovara BIC-u banke poverioct 

(CreditorAgent) 

rtnnnnnnnnnnnn - broj računa 

KB - kontrolni broj za broj računa bez oznake države (DD) i 
kontrolnog broja (KK) 

2.45 

CreditorAgent.BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

2.57 

Debtor.Debtorld 

Struktura identifikatora u domaćem platnom prometu: 

Matični broj, dužine 8 - ukoliko se radi o Dužniku pravnom licu 
JMBG, dužine 13 - ukoliko se radi o Dužniku fizičkom licu koje 
obavlja delatnost 

Kontrola dužine . 

2.57 

Debtor. CountryCode 

Iz šifarnika država 

2.58 

DebtorAccount. 

Struktura broja računa u domaćem platnom prometu: 
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IBANAccount 

DDKKBBBnnnnnnnnnnnnnKB 

Gde je: 

DD - oznaka države (fiksna vrednost RS za Srbiju) 

KK - kontrolni broj po modelu 97 za ceo IBAN račun (fiksna 
vrednost 35 za Srbiju) 

BBB - šifra banke koja odgovara BIC-u banke dužnika 
(DebtorAgent) 

nnnnnnnnnnnnn - broj računa 

KB - kontrolni broj za broj računa bez oznake države (DD) i 
kontrolnog broja (KK) 

2.59 

DebtorAgent.BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

2.72 

StatusOriginator. 

BlCOriginator 

Inicijatori prihvtanja mogu biti Banka Poverioca, Banka Dužnika 
ili Procesor, koji se identifikuju BlC-om i koji mora biti u 
evidenciji aktivnih učesnika kliringa za direktna zaduženja. 
(Inicijatori mogu biti i Dužnik ili Poverilac, koji se identifikuju 
svojim nazivom, ali se ne vrši kontrola od strane Procesora) 

2.105 

AdditionalReasonlnformation 

Može se zadati tekstualni opis razloga prihvatnja (bez kontrole 
Procesora) 


PORUKA mndt.005.001.01REQUEST&CANCELLATION 
Struktura: SerbianCancel 

• Koristi se za povlačenje instrukcija za evidentiranje, izmenu i povlačenje Mandata (pojedinačno ili 
celih рошка). 

• Element OriginalMessageName ima vrednost tipa instrukcije koja se povlači (mndt.001.001.01 ili 
mndt.002.001.01) 

• Generišu je i ispostavljaju Procesoru banke koje koriste dodatni servis vođenja Registra mandata, pre 
realizacije instrukcije koja se povlači. 


Index 

Kardin 

alnost 

Element poruke 

Tip 

Opis 

1.0 

M 1 

+ 

Header 

GroupHeader 

Zaglavlje poruke 

1.1 

M 1 

+ 

+ 

Messageld 

Max35Text 

Jedinstveni identifikator 
poruke koji formira 
pošiljalac poruke 

1.2 

M 1 

+ 

+ 

CreationDate 

ISODateTime 

Datum kreiranja poruke 

1.3 

M 1 

+ 

+ 

InstructingAgent 

Financial 

Institution2 

Pošiljalac poruke 

1.3 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

Identification4 

Identifikacija pošiljaoca 
poruke 

1.3 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC pošiljaoca poruke 

1.4 

М 1 

+ 

+ 

InstructedAgent 

Financial 

Institution2 

Primalac poruke 

1.4 

М 1 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija primaoca 
poruke 

1.4 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC primaoca poruke 

2.0 

М 1-n 

+ 

Transactionlnformation 

Transaction 

Information 

Telo poruke za 

povlačenje poruke ili 
pojedinačne instrukcije 

2.1 

М 1 

+ 

+ 

Transactionld 

Max35Text 

Jedinstveni Id transakcije 
podnosioca instrukcije 

2.2 

М 1 

+ 

+ 

OriginalT ransactionlnformation 

OriginalT ransaction 
Information 

Identifikacija originalne 
poruke 

2.3 

М 1 

+ 

+ 

+ 

OriginalMessageld 

Max35Text 

Jedinstveni identifikator 
originalne poruke 

2.4 

М 1 

+ 

+ 

+ 

OriginalMessageName 

Max35Text 

Naziv originalne poruke. 

2.5 

0 0-1 

+ 

+ 

+ 

OriginalCreationDate 

ISODateTime 

Datum kreiranja 

originalne poruke 
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2.6 

0 0-n 

+ 

+ 

OriginalT ransactionld 

Max35Text 

Id transakcije banke 
podnosioca instrukcije iz 
originalne instrukcije 

2.7 

M 1 

+ 

+ 

T ransactionStatus 

Trnsactionlndividual 

Status2Code 

Vrednost: CNCL 


POSLOVNA PRAVILA 


Index 

Element poruke 

Poslovna pravila 

1.1 

Messageld 

U sistemu je jedinstven na nivou pošiljaoca. 

U slučaju standardizacije identifikatora u domaćem platnom 
prometu, kontrolu vršiti prema usvojenom standardu 

1.2 

CreationDate 

Manji tli jednak od tekućeg datume 

1.3 

InstructingAgent. BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

1.4 

InstructedAgent. BICAgent 

Mora biti u evidenciji aktivnih učesnika kliringa za direktna 
zaduženja 

2.1 

Transactionld 

Predstavlja ID Reques&Cancellation instrukcije koji generiše 
banka koja je uputila originalnu instrukciju 

U slučaju standardizacije identifikatora u domaćem platnom 
prometu, kontrolu vršiti prema usvojenom standardu 

2.3 

OriginalMessageld 

Messageld iz Header-a poruke u kojoj se nalazila originalna 
instrukcija. 

Predstavljajedinstveni identifikator poruke u kojoj se nalazi 
originalna instrukcije 

Kontrola postojanja poruke u evidenciji procesora 

2.4 

OriginalMessageName 

Može biti: 

mndt.001.001.01, za povlačenje instrukcije Mandate 
mndt.002.001.01, za povlačenje instrukcije Remove Mandate 

2.5 

OriginalCreationDate 

CreationDate iz Header-a poruke u kojoj se nalazila originalna 
instrukcija 

2.6 

OriginalT ransactionld 

TransactionlD iz originalne instrukcije koja se povlači 

Kontrola postojanja instrukcije u evidenciji procesora 

2.7 

TransactionStatus 

Vrednost: CNCL 


PORUKA mndt.006.001.01 MANDATE QUERY 
Struktura: SerbianMandateQuery 

• Koristi se za ispostavljanje zahteva za dobijanjem informacija o mandatu evidentiranih u Registru 
mandata. 


• Generišu je i ispostavljaju Procesoru banke koje koriste dodatni servis vođenja Registra mandata. 


Index 

Kardin 

alnost 



Element poruke 

Tip 

Opis 

1.0 

M 1 

+ 

Header 

GroupHeader 

Zaglavlje poruke 

1.1 

M 1 

+ 

+ 

Messageld 

Max35Text 

Jedinstveni identifikator 
poruke koji formira 

pošiljalac poruke 

1.2 

M 1 

+ 

+ 

CreationDate 

ISODateTime 

Datum kreiranja poruke 

1.3 

M 1 

+ 

+ 

InstructingAgent 

FinancialInstitution2 

Pošiljalac poruke 

1.3 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

Identification4 

Identifikacija pošiljaoca 
poruke 

1.3 

М 1 

+ 

+ 

+ 

+ BICAgent 

BlCldentifier 

BIC pošiljaoca poruke 

1.4 

М 1 

+ 

+ 

InstructedAgent 

FinancialInstitution2 

Primalac poruke 

1.4 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

Identification4 

Identifikacija primaoca 
poruke 

1.4 

М 1 

+ 

+ 

+ 

+ BICAgent 

BlCldentifier 

BIC primaoca poruke 

2.0 

М 1 

+ 

Transactionlnformation 

Transaction 

Information 

Telo poruke za upit u 
Registar mandata 

2.1 

М 1 

+ 

+ 

Transactionld 

Max35Text 

Jedinstveni identifikator 
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upita 

2.2 

0 0-n 

+ 

+ 

Mandate 

Mandateldentification 

Identifikacija mandata ili 
aneksa 

Upit za dati mandat ili 
aneks 

2.2 

0 0-1 

+ 

+ 

+ 

Mandateld 

Max35Text 

Identifikacija mandata ili 
aneksa 

2.2 

0 0-1 

+ 

+ 

+ 

Amendmentlndicator 

TrueFalselndicator 

Indikator aneksa 

2.3 

0 0-1 

+ 

+ 

MandateStatus 

Mandatelndividual 

Status2Code 

Status mandata 

Upit po statusu mandata 

2.4 

0 0-n 

+ 

+ 

Creditor 

PartyIdentification 13 

Poverilac 

Upit po poveriocu 

2.4 

0 0-1 

+ 

+ 

+ 

Creditorld 

Max35Text 

Id dužnika, matični broj ili 
Jmbg 

2.4 

0 0-1 

+ 

+ 

+ 

Name 

Max70Text 

Ime poverioca 

2.5 

0 0-n 

+ 

+ 

CreditorAccount 

CashAccount8 

Broj računa poverioca 

Upit po broju računa 
poverioca 

2.5 

0 0-1 

+ 

+ 

+ 

Accountld 

Accountldentification2 

Identiflkacija računa 

poverioca 

2.5 

0 0-1 

+ 

+ 

+ 

+ 

IBANAccount 

IBANldentifier 

IBAN broj računa 

poverioca 

2.6 

0 0-n 

+ 

+ 

CreditorAgent 

Financiallnstitution3 

Banka poverioca 

Upit po banci poverioca 

2.6 

0 0-1 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification5 

Identifikacija banke 

poverioca 

2.6 

0 0-1 

+ 

+ 

+ 

+ 

BICAgent 

BIC Identifier 

BIC banke poverioca 

2. 7 

0 0-n 

+ 

+ 

Debtor 

PartyIdentificationl9 

Dužnika 

Upit po dužniku 

2.7 

0 0-1 

+ 

+ 

+ 

Debtorld 

Max35Text 

Id dužnika, matični broj ili 
Jmbg 

2.7 

0 0-1 

+ 

+ 

+ 

Name 

Max70Text 

Ime dužnika 

2.8 

0 0-n 

+ 

+ 

DebtorAccount 

CashAccount8 

Broj računa dužnika 

Upit po računu dužnika 

2.8 

0 0-1 

+ 

+ 

+ 

Accountld 

Accountldentification2 

Identifikacija računa 

dužnika 

2.8 

0 0-1 

+ 

+ 

+ 

+ 

IBANAccount 

IBANldentifier 

IBAN broj računa 

dužnika 

2.9 

0 0-n 

+ 

+ 

DebtorAgent 

FinancialInstitution3 

Banka dužnika 

Upit po banci dužnika 

2.9 

0 0-1 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification5 

Identifikacija banke 

dužnika 

2.9 

0 0-1 

+ 

+ 

+ 

+ 

BICAgent 

BIC Identifier 

BIC banke dužnika 


POSLOVNA PRAVILA 


Index 

Element poruke 

Poslovna pravila 

1.1 

Messageld 

U sistemu je jedinstven na nivou pošiljaoca 

1.2 

CreationDate 

Jednak tekućem datumu 

1.3 

InstructingAgent. BICAgent 

Mora biti u evidenciji učesnika kliringa za direktna zaduženja 

1.4 

InstructedAgent. BICAgent 

BIC Procesora 

2.1 

Transactionld 

Predstavlja ID upita koji generiše banka koja je uputila upit 

U slučaju standardizacije identifikatora u domaćem platnom 
prometu, kontrolu vršiti prema usvojenom standardu 

2.4 

Creditorld 

Id poverioca, matični broj ili Jmbg 

Mora postojati ili identifikacija poverioca ili identifikacija 
dužnika (2.7) 

2.7 

Debtorld 

Id dužnika, matični broj ili Jmbg 
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Мога postojati ili identifikacija dužnika ili identifikacija 

_ poverioca (2.4) _ 

Napomena: Nije potrebno vršiti dodatne kontrole sadržaja рошке, s obzirom da će rezultat upita (odgovor 
procesora) biti u skladu sa ,,kvalitetom“ podataka u upitu 

PORUKA mndt.007.001.01 MANDATE RESPONSE 
Struktura: SerbianMandateResponse 

• Koristi se za davanje odgovora na podneti zahtev za dobijanjem informacija o mandatu evidentiranih 
u Registru mandata. 

• Generišu ih i ispostavljaju Procesoru, banke koje koriste dodatni servis vođenja Registra mandata i 
koje su podnele zahtev za dobijanjem informacija o mandatu . 


Index 

Kardin 

alnost 

Element poruke 

Tip 

Opis 

1.0 

M 1 

+ 

Header 

GroupHeader 

Zaglavlje poruke 

1.1 

M 1 

+ 

+ 

Messageld 

Max35Text 

Jedinstveni 
identifikator poruke 
koji formira 

pošiljalac poruke 

1.2 

M 1 

+ 

+ 

CreationDate 

ISODateTime 

Datum kreiranja 

poruke 

1.3 

M 1 

+ 

+ 

InstructingAgent 

Financial 

Institution2 

Pošiljalac poruke 

1.3 

М 1 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija 
pošiljaoca poruke 

1.3 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC pošiljaoca 

poruke 

1.4 

М 1 

+ 

+ 

InstructedAgent 

Financial 

Institution2 

Primalac poruke 

1.4 

М 1 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija 
primaoca poruke 

1.4 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC primaoca 

poruke 

2.0 

М 1 

+ 

Transactionlnformation 

Transaction 

Information 

Odgovor na 

postavljeni upit 

2.1 

М 1 

+ 

+ 

Transactionld 

Max35Text 

Jedinstveni 

identifikator odgovora 
na upit 

2.2 

М 1 

+ 

+ 

OriginalT ransactionld 

Max35Text 

Id transakcije 

podnosioca upita iz 
originalne instrukcije 

2.3 

OO-n 

+ 

+ 

QueryResponse 

QueryAndResponse 

Odgovor na upit 

2.4 

М 1 

+ 

+ 

+ 

MandateStatus 

Mandatelndividual 

Status2Code 

Status mandata iz 
internog šifamika 
Procesora 

2.5 

М 1 

+ 

+ 

+ 

Mandatelnformation 

Mandate 

Information3 

Informacije o 

mandatu 

2.6 

0 0-1 

+ 

+ 

+ 

+ 

Contractld 

Max35Text 

Broj ugovora po 
kome je izdat mandat 

2.10 

М 1 

+ 

+ 

+ 

+ 

MandateType 

MandateType 

Information8 

Tip mandata 

2.11 

М 1 

+ 

+ 

+ 

+ 

+ 

SequenceType 

SequenceT уре 1 Code 

Vrednosti: RECR, 

ONEO 

2.22 

М 1 

+ 

+ 

+ 

+ 

Mandatld 

Max35Text 

Identifikacija mandata 
ili aneksa 

2.23 

М 1 

+ 

+ 

+ 

+ 

DateSignature 

ISODate 

Datum potpisivanja 
mandata ili aneksa 

2.24 

М 1 

+ 

+ 

+ 

+ 

Amendmentlndicator 

T rueF alselndicator 

Indikator aneksa 

(izmena mandata) 
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2.25 

0 0-1 

+ 

+ 

+ 

+ 

Amendmentlnformation 

Amendment 

InformationDetails4 

Informacije o 

osnovnom mandatu 

2.26 

0 0-1 

+ 

+ 

+ 

+ 

+ 

OrgMandateld 

Max35Text 

Identifikator 
osnovnog mandata 

2.43 

M 1 

+ 

+ 

+ 

Creditor 

Party 

Identificationl3 

Poverilac 

2.43 

M 1 

+ 

+ 

+ 

+ 

Debtorld 

Max35Text 

Id dužnika, matični 
broj ili Jmbg 

2.43 

M 1 

+ 

+ 

+ 

+ 

Name 

Max70Text 

Ime poverioca 

2.43 

0 0-1 

+ 

+ 

+ 

+ 

PostAddress 

PostalAddress4 

Poštanska adresa 

poverioca 

2.43 

0 0-2 

+ 

+ 

+ 

+ 

f 

Address 

Max70Text 

Adresa poverioca 

2.43 

M 1 

+ 

+ 

+ 

+ 

f 

CountryCode 

CountryCode 

Kod države poverioca 

2.44 

М 1 

+ 

+ 

+ 

CreditorAccount 

CashAccount8 

Broj računa 

poverioca 

2.44 

М 1 

+ 

+ 

+ 

+ 

Accountld 

Account 

Identification2 

Identifikacija računa 
poverioca 

2.44 

М 1 

+ 

+ 

+ 

+ 

+ 

IBANAccount 

IBANldentifier 

IBAN broj računa 
poverioca 

2.45 

М 1 

+ 

+ 

+ 

CreditorAgent 

FinancialInstitution2 

Banka poverioca 

2.45 

М 1 

+ 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija banke 
poverioca 

2.43 

М 1 

+ 

+ 

+ 

+ 

+ 

BICAgent 

BIC Identifier 

BIC banke poverioca 

2.57 

М 1 

+ 

+ 

+ 

Debtor 

Party 

Identificationl9 

Dužnika 

2.57 

М 1 

+ 

+ 

+ 

+ 

Debtorld 

Max35Text 

Id dužnika, matični 
broj ili Jmbg 

2.57 

М 1 

+ 

+ 

+ 

+ 

Name 

Max70Text 

Ime dužnika 

2.57 

0 0-1 

+ 

+ 

+ 

+ 

PostAddress 

PostalAddress4 

Poštanska adresa 

dužnika 

2.57 

0 0-2 

+ 

+ 

+ 

+ 

+ 

Address 

Max70Text 

Adresa dužnika 

2.57 

М 1 

+ 

+ 

+ 

+ 

+ 

CountryCode 

CountryCode 

Kod države dužnika 

2.58 

М 1 

+ 

+ 

+ 

DebtorAccount 

CashAccount8 

Broj računa dužnika 

2.58 

М 1 

+ 

+ 

+ 

+ 

Accountld 

Account 

ldentification2 

Identifikacija računa 
dužnika 

2.58 

М 1 

+ 

+ 

+ 

+ 

+ 

IBANAccount 

IBANldentifier 

IBAN broj računa 
dužnika 

2.59 

М 1 

+ 

+ 

+ 

DebtorAgent 

FinancialInstitution2 

Banka dužnika 

2.59 

М 1 

+ 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija banke 
dužnika 

2.59 

М 1 

+ 

+ 

+ 

+ 

+ 

BICAgent 

BIC Identifier 

BIC banke dužnika 

2.81 

0 0-1 

+ 

+ 

+ 

Remmitancelnformation 

Remittance 

Information3 

Informacije o 

plaćanju 

2.82 

0 0-n 

+ 

+ 

+ 

+ 

UnstructuredRemmitance 

Maxl40Text 

Nestruktuirane 
informacije o plaćanju 

2.83 

М 1 

+ 

+ 

+ 

+ 

StructuredRemmitance 

StructuredRemittance 

Informationć 

Struktuirane 
informacije o plaćanju 

2.84 

М 1 

+ 

+ 

+ 

+ 

+ 

F irstCollectionDate 

ISODate 

Datum kada može da 
bude realizovana 

prvo zaduženje 

2.84 

0 0-1 

+ 

+ 

+ 

+ 

+ 

F inalCollectionDate 

ISODate 

Datum do koga 
može da bude 

izvršavana poslednje 
zaduženje (Datum 
isteka Mandata) 

2.85 

М 1 

+ 

+ 

+ 

+ 

+ 

Revocation 

Revocation 

Identificationl 

Opozivost Mandata 

2.85 

М 1 

+ 

+ 

+ 

+ 

+ 

+ Revocationlndicator 

T rueFalselndicator 

Indikator opozivosti 
Mandata 
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2.85 

0 0-1 

+ 

+ 

+ 

+ 

+ 

+ 

Conditional 

Maxl40Text 

Uslovi opoziva 

Mandata 

2.86 

M 1 

+ 

+ 

+ 

+ 

+ 

NumberOfCollection 

Мах 15N umericT ext 

Maksimalni bro 

obaveza po mandatu 

2.87 

M 1 

+ 

+ 

+ 

+ 

+ 

TotalAmount 

EuroMax9Amount 

Ukupan iznos 

zaduženja po mandatu 

2.87 

M 1 

+ 

+ 

+ 

+ 

+ 

+ 

Amount 

Decimal, 9,2 

Ukupan iznos 

plaćanja. 

2.87 

M 1 

+ 

+ 

+ 

+ 

+ 

+ 

CurrencyCode 

EuroCurrencyCode 

Kod valute 

2.88 

0 0-1 

+ 

+ 

+ 

+ 

+ 

Frequency Metric 

FrequencyMetric 

Metrika dospeća 

2.88 

М 1 

+ 

+ 

+ 

+ 

+ 

+ 

Frequency Code 

FrequencyCode 

Kodirana metrika 

dospeća: 

DAIL, za dan, 
MNTH, za mesec 
YEAR, za godinu 

2.88 

М 1 

+ 

+ 

+ 

+ 

+ 

+ 

Periodic 

Мах 15N umericT ext 

Periodika dospeća u 
datoj metrici 

2.89 

0 0-n 

+ 

+ 

+ 

+ 

+ 

FixedReqDate 

ISODate 

Fiksni datumi 

dospeća (DueDate) 

2.90 

0 0-1 

+ 

+ 

+ 

+ 

+ 

Tolerancy 

Tolerancy 

Period tolerancije 
dospeća u danima 

2.91 

М 1 

+ 

+ 

+ 

+ 

+ 

+ 

TolerancySign 

TolerancySign 

Kodirani znak 

perioda tolerancije: 
PLS, po dospeću 
(PLUS) 

MNS, pre dospeća 
(MINUS) 

BTH, pre i posle 
dospeća (BOTH) 

2.91 

М 1 

+ 

+ 

+ 

+ 

+ 

+ 

TolerancyValue 

Мах 15N umericT ext 

Broj dana tolerancije 
u dospeću 

2.92 

0 0-1 

+ 

+ 

+ 

+ 

+ 

DebitAmount 

EuroMax9Amount 

Maksimalni iznos u 
jednom nalogu 

zaduženja (collection) 

2.92 

М 1 

+ 

+ 

+ 

+ 

+ 

+ 

Amount 

Decimal, 9,2 

Iznos plaćanja. 

2.92 

М 1 

+ 

+ 

+ 

+ 

+ 

+ 

CurrencyCode 

EuroC urrencyCode 

Kod valute 

2.93 

0 0-1 

+ 

+ 

+ 

+ 

+ 

Exchange 

Exchange 

Valutni uslovi 

plaćanja 

2.93 

М 1 

+ 

+ 

+ 

+ 

+ 

+ 

CurrencyCode 

CurrencyCode 

Kod valute plaćanja 

2.93 

М 1 

+ 

+ 

+ 

+ 

+ 

+ 

ExchangeRate 

BaseOnRate 

Kurs ugovorene 

valute: 

SEL - prodajni kurs 
MID - srednji kurs 
BUY - kupovni kurs 

2.93 

М 1 

+ 

+ 

+ 

+ 

+ 

+ 

Exchange list 

BaseOnList 

Vrednosti : 

NBS - za kursnu listu 
Narodne banke 

BANK - za kursnu 
listu banke (nije 
osnov za kontrolu 
Procesora) 

2.97 

0 0-1 

+ 

+ 

+ 

+ 

+ 

CreditorReference 

CreditorReferenc 

Informationl 

Identifikator dužnika 

2.97 

0 0-1 

+ 

+ 

+ 

+ 

+ 

+ 

ReferenceType 

CreditorReference 

Typel 

Referenca 

2.97 

0 0-1 

+ 

+ 

+ 

+ 

+ 

+ 

+ 

Purport 

Max35Text 

Poziv na broj 

dužnika 

2.105 

0 0-1 

+ 

+ 

+ 

+ 

+ 

AdditionalRemmitance 

Maxl40Text 

Dodatne informacije o 
plaćanju 
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POSLOVNA PRAVILA 


Index 

Element poruke 

Poslovna pravila 

1.1 

Messageld 

U sistemu je jedinstven na nivou pošiljaoca. 

U slučaju standardizacije identifikatora u domaćem platnom 
prometu, kontrolu vršiti prema usvojenom standardu 

1.2 

CreationDate 

Jednak tekućem datumu 

1.3 

InstructingAgent.BICAgent 

BIC Procesora 

1.4 

InstructedAgent. BICAgent 

Mora biti u evidenciji učesnika kliringa za direktna zaduženja 

2.1 

Transactionld 

Predstavlja ID upita koji generiše banka koja je uputila upit 

U slučaju standardizacije identifikatora u domaćem platnom 
prometu, kontrolu vršiti prema usvojenom standardu 


Napomena: Nije potrebno vršiti dodatne kontrole sadržaja рошке, s obzirom da će rezultat upita (odgovor 
procesora) biti u skladu sa ,,kvalitetom“ podataka u upitu 
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Prilog 6. 

TEHNIČKO UPUTSTVO 

ZA REALIZACIJU DODATNIH SERVISA DIREKTNOG ZADUŽENJA 
Jun, 2008. godine 

PORUKA mndt.001.001.01 MANDATE 
Struktura: SerbianMandateEvidence 

• Koristi se za evidentiranje i izmenu sadržaja Mandata. Generišu je i ispostavljaju Procesoru banke 
koje koriste dodatni servis vođenja Registra mandata 

• Ukoliko se koristi kao instrukcija za evidendtiranje Mandata, element Amendmentlndicator ima 
vrednost FALSE 


• Ukoliko se koristi kao instrukcija za izmenu sadržaja Mandata, element Amendmentlndicator ima 
vrednost TRUE, a element OrgMandateld vrednost identifikatora osnovnog mandata 


Index 

Kardin 

alnost 

Element poruke 

Tip 

Opis i poslovna 
pravila 

1.0 

M 1 

+ 

Header 

GroupHeaderl 

Zaglavlje poruke 

1.1 

M 1 

+ 

+ 

Messageld 

Max35Text 

Jedinstveni 

identifikator poruke 
koji formira pošiljalac 
poruke. 

1.2 

M 1 

+ 

+ 

CreationDate 

ISODateTime 

Datum kreiranja 

poruke. 

1.26 

M 1 

+ 

+ 

InstructingAgent 

FinancialInstitution2 

Pošiljalac poruke 

1.26 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

Identification4 

Identifikacija 

pošiljaocaporuke 

1.26 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCIdentifier 

BIC pošiljaoca poruke 

1.27 

М 1 

+ 

+ 

InstructedAgent 

FinancialInstitution2 

Primalac poruke 

1.27 

М 1 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija 
primaoca poruke 

1.27 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC primaoca poruke 

2.0 

М 1-n 

f 

Transactionlnformation 

Transaction 

Information3 

Telo poruke za 
evidentiranje 

Mandata 

2.1 

М 1 

+ 

+ 

Transactionld 

Max35Text 

Jedinstveni Id 

transakcije 
podnosioca 
instrukcije. 

2.2 

М 1 

+ 

+ 

Mandatlnformation 

MandateInformation3 

Informacije o 

mandatu 

2.3 

О 0-1 

+ 

+ 

+ 

Contractld 

Max35Text 

Broj ugovora po kome 
je izdat mandat 

2.10 

М 1 

+ 

+ 

+ 

MandateType 

MandateType 

Information8 

Tip mandata 

2.11 

М 1 

+ 

+ 

+ 

+ 

SequenceType 

SequenceT уре 1 Code 

Vrednosti: RECR, 

ONEO 

2.22 

М 1 

+ 

+ 

+ 

Mandatld 

Max35Text 

Identifikacija mandata 
ili aneksa 

2.23 

М 1 

+ 

+ 

+ 

DateSignature 

ISODate 

Datum potpisivanja 
mandata ili aneksa 

2.24 

М 1 

+ 

+ 

+ 

Amendmentlndicator 

T rueF alselndicator 

Indikator aneksa 

(izmena mandata) 

2.25 

О 0-1 

+ 

+ 

+ 

Amendmentlnformation 

Amendment 

InformationDetails4 

Informacije o 

osnovnom mandatu 

2.26 

О 0-1 

+ 

+ 

+ 

+ 

OrgMandateld 

Max35Text 

Identifikator 
osnovnog mandata 

2.43 

М 1 

+ 

+ 

Creditor 

PartyIdentificationl3 

Poverilac 

2.43 

М 1 

+ 

+ 

+ 

Creditorld 

Max35Text 

Id poverioca, matični 
broj ili Jmbg 
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2.43 

M 1 

+ 

+ 

+ 

Name 

Max70Text 

Ime poverioca 

2.43 

0 0-1 

+ 

+ 

+ 

PostAddress 

PostalAddress4 

Poštanska adresa 

poverioca 

2.43 

0 0-5 

+ 

+ 

+ 

f 

Address 

Max70Text 

Adresa poverioca 

2.43 

M 1 

+ 

+ 

+ 

f 

CountryCode 

CountryCode 

Kod države poverioca 

2.44 

M 1 

+ 

+ 

CreditorAccount 

CashAccount8 

Broj računa poverioca 

2.44 

M 1 

+ 

+ 

+ 

Accountld 

Account 

Identification2 

Identifikacija računa 
poverioca 

2.44 

М 1 

+ 

+ 

+ 

+ 

IBANAccount 

IBANldentifier 

IBAN broj računa 
poverioca 

2.45 

М 1 

+ 

+ 

CreditorAgent 

FinancialInstitution2 

Banka poverioca 

2.45 

М 1 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija banke 

poverioca 

2.43 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCIdentifier 

BIC banke poverioca 

2.57 

М 1 

+ 

+ 

Debtor 

PartyIdentificationl9 

Dužnika 

2.57 

М 1 

+ 

+ 

+ 

Debtorld 

Max35Text 

Id dužnika, matični 
broj ili Jmbg 

2.57 

М 1 

+ 

+ 

+ 

Name 

Max70Text 

Ime dužnika 

2.57 

0 0-1 

+ 

+ 

+ 

PostAddress 

PostalAddress4 

Poštanska adresa 

dužnika 

2.57 

0 0-5 

+ 

+ 

+ 

+ 

Address 

Max70Text 

Adresa dužnika 

2.57 

М 1 

+ 

+ 

+ 

+ 

CountryCode 

CountryCode 

Kod države dužnika 

2.58 

М 1 

+ 

+ 

DebtorAccount 

CashAccount8 

Broj računa dužnika 

2.58 

М 1 

+ 

+ 

+ 

Accountld 

Account 

ldentification2 

Identifikacija računa 
dužnika 

2.58 

М 1 

+ 

+ 

+ 

+ 

IBANAccount 

IBANldentifier 

IBAN broj računa 
dužnika 

2.59 

М 1 

+ 

+ 

DebtorAgent 

FinancialInstitution2 

Banka dužnika 

2.59 

М 1 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija banke 

dužnika 

2.59 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC banke dužnika 

2.81 

0 0-1 

+ 

+ 

Remmitancelnformation 

Remittance 

Information3 

Informacije o 

plaćanju 

2.82 

0 0-n 

+ 

+ 

+ 

UnstructuredRemmitance 

Maxl40Text 

Nestruktuirane 
informacije o plaćanju 

2.83 

М 1 

+ 

+ 

+ 

StructuredRemmitance 

StructuredRemittance 

Information6 

Struktuirane 
informacije o plaćanju 

2.84 

М 1 

+ 

+ 

+ 

+ 

FirstCollectionDate 

ISODate 

Datum kada može da 
bude realizovana prvo 
zaduženje 

2.85 

0 0-1 

+ 

+ 

+ 

+ 

FinalCollectionDate 

ISODate 

Datum do koga može 
da bude izvršavana 
poslednje zaduženje 

2.86 

М 1 

+ 

+ 

+ 

+ 

NumberOfCollection 

Мах 15N umericT ext 

Maksimalni bro 

obaveza po mandatu 

2.87 

М 1 

+ 

+ 

+ 

+ 

TotalAmount 

EuroMax9 Amo unt 

Ukupan iznos 

zaduženja po mandatu. 

2.87 

М 1 

+ 

+ 

+ 

+ 

+ 

Amount 

Decimal, 9,2 

Ukupan iznos 

plaćanja. 

2.87 

М 1 

+ 

+ 

+ 

+ 

+ 

CurrencyCode 

EuroCurrencyCode 

Kod valute 

2.88 

0 0-1 

+ 

+ 

+ 

+ 

Frequency Metric 

FrequencyMetric 

Metrika dospeća 

2.88 

М 1 

+ 

+ 

+ 

+ 

+ 

Frequency Code 

FrequencyCode 

Kodirana metrika 

dospeća: 

DAIL, za dan, 

MNTH, za mesec 
YEAR, za godinu 

2.88 

М 1 

+ 

+ 

+ 

+ 

+ 

Periodic 

Мах 15NumericT ext 

Periodika dospeća u 
datoj metrici 

2.89 

0 0-n 

+ 

+ 

+ 

+ 

FixedReqDate 

ISODate 

Fiksni datumi dospeća 


Slobodan Babić \ Fakidtet organizacionih nauka 


403 




























































Doktorska disertacija: Model interoperabilnog elektronskog poslovanja platnih sistema zasnovanih na ontologijama 










(DueDate) 

2.90 

O 0-1 

+ 

+ 

+ 

+ 

Tolerancy 

Tolerancy 

Period tolerancije 

dospeća u danima 

2.90 

M 1 

+ 

+ 

+ 

+ 

+ 

TolerancySign 

TolerancySign 

Kodirani znak perioda 
tolerancije: 

PLS, po dospeću 
(PLUS) 

MNS, pre dospeća 
(MINUS) 

BTH, pre i posle 
dospeća (BOTH) 

2.90 

M 1 

+ 

+ 

+ 

+ 

+ 

TolerancyValue 

Мах 15NumericT ext 

Broj dana tolerancije u 
dospeću 

2.91 

O 0-1 

+ 

+ 

+ 

+ 

DebitAmount 

EuroMax9 Amo unt 

Maksimalni iznos u 
jednom nalogu 

zaduženja (collection) 

2.91 

M 1 

+ 

+ 

+ 

+ 

+ 

Amount 

Decimal, 9,2 

Iznos plaćanja. 

2.91 

M 1 

+ 

+ 

+ 

+ 

+ 

CurrencyCode 

EuroCurrencyCode 

Kod valute 

2.92 

О 0-1 

+ 

+ 

+ 

+ 

Exchange 

Exchange 

Valutni uslovi plaćanja 

2.92 

М 1 

+ 

+ 

+ 

+ 

+ 

CurrencyCode 

CurrencyCode 

Kod valute plaćanja 

2.92 

М 1 

+ 

+ 

+ 

+ 

+ 

ExchangeRate 

BaseOnRate 

Kurs ugovorene valute: 
SEL - prodajni kurs 
MID - srednji kurs 
BUY - kupovni kurs 

2.92 

М 1 

+ 

+ 

+ 

+ 

+ 

Exchange list 

BaseOnList 

Vrednosti : 

NBS - za kursnu listu 
Narodne banke 

BANK - za kursnu 
listu banke (nije osnov 
za kontrolu Procesora) 

2.97 

О 0-1 

+ 

+ 

+ 

+ 

CreditorReference 

CreditorReference 

Informationl 

Referisanje poverioca 
na Identifikator 

dužnika 

2.97 

О 0-1 

+ 

+ 

+ 

+ 

+ 

ReferenceType 

CreditorReference 

Typel 

Referenca 

2.97 

О 0-1 

+ 

+ 

+ 

+ 

+ 

+ Purport 

Max35Text 

Poziv na broj dužnika 

2.105 

О 0-1 

+ 

+ 

+ 

+ 

AdditionalRemmitance 

Maxl40Text 

Dodatne informacije o 
plaćanju 


PORUKA mndt.002.001.01 STATUS MANDATE 
Struktura: SerbianMandateStatus 

• Koristi se za povlačenje Mandata i potvrdu aktivnog statusa Mandata. Generišu je i ispostavljaju 
Procesoru banke koje koriste dodatni servis vođenja Registra mandata 

• Ukoliko se koristi kao instrukcija za povlačenje Mandata, element MandateStatus ima vrednost 
CANCEL 


• Ukoliko se koristi kao instrukcija za prihvatanje evidetiranja, odnosno izmene Mandata, element 
MandateStatus ima vrednost LIVE 


Index 

Kardin 

alnost 

Element poruke 

Tip 

Opis i poslovna 
pravila 

1.0 

M 1 

+ 

Header 

GroupHeaderl 

Zaglavlje poruke 

1.1 

M 1 

+ 

+ 

Messageld 

Max35Text 

Jedinstveni 

identifikator poruke 
koji formira pošiljalac 
poruke. 

1.2 

M 1 

+ 

+ 

CreationDate 

ISODateTime 

Datum kreiranja 

poruke. 

1.26 

M 1 

+ 

+ 

InstructingAgent 

Finaneial 

Institution2 

Pošiljalac poruke 
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1.26 

M 1 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

Identification4 

Identifikacija 

pošiljaocaporuke 

1.26 

M 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC pošiljaoca poruke 

1.27 

M 1 

+ 

+ 

InstructedAgent 

Financial 

lnstitution2 

Primalac poruke 

1.27 

M 1 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

Identification4 

Identifikacija 
primaoca poruke 

1.27 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC primaoca poruke 

2.0 

М 1-n 

f 

Transactionlnformation 

Transaction 

Information3 

Telo poruke za 
evidentiranje 

Mandata 

2.1 

М 1 

+ 

+ 

Transactionld 

Max35Text 

Jedinstveni Id 

transakcije 
podnosioca 
instrukcije. 

2.2 

М 1 

+ 

+ 

Mandatlnformation 

Mandate 

Information3 

Informacije o 

mandatu 

2.3 

0 0-1 

+ 

+ 

+ 

Contractld 

Max35Text 

Broj ugovora po kome 
je izdat mandat 

2.10 

М 1 

+ 

+ 

+ 

MandateType 

MandateType 

lnformation8 

Tip mandata 

2.11 

М 1 

+ 

+ 

+ 

+ 

SequenceType 

SequenceTypel Code 

Vrednosti: RECR, 

ONEO 

2.22 

М 1 

+ 

+ 

+ 

Mandatld 

Max35Text 

Identifikacija mandata 
ili aneksa 

2.23 

М 1 

+ 

+ 

+ 

DateSignature 

ISODate 

Datum potpisivanja 
mandata ili aneksa 

2.24 

М 1 

+ 

+ 

+ 

Amendmentlndicator 

T rueF alselndicator 

Indikator aneksa 

(izmena mandata) 

2.25 

0 0-1 

+ 

+ 

+ 

Amendmentlnformation 

Amendment 

InformationDetails4 

Informacije o 

osnovnom mandatu 

2.26 

О 0-1 

+ 

+ 

+ 

+ 

OrgMandateld 

Max35Text 

Identifikator 
osnovnog mandata 

2.43 

М 1 

+ 

+ 

Creditor 

Party 

Identificationl3 

Poverilac 

2.43 

М 1 

+ 

+ 

+ 

Debtorld 

Max35Text 

Id dužnika, matični 
broj ili Jmbg 

2.57 

М 1 

+ 

+ 

Debtor 

Party 

Identificationl9 

Dužnika 

2.57 

М 1 

+ 

+ 

+ 

Debtorld 

Max35Text 

Id dužnika, matični 
broj ili Jmbg 

2.60 

М 1 

+ 

+ 

MandateStatus 

Mandatelndividual 

Status2Code 

Vrednosti: 

CANCEL, za 

povlačenje mandata 
LIVE, za potvrdu 
prihvatanja mandata i 
izmene mandata 

2.92 

О 0-1 

+ 

+ 

AdditionalReasonlnformation 

Maxl05Text 

Dodatno obrazloženje 
za promenu statusa 
mandata 


PORUKA mndt.003.001.01 REJECT MANDATE 
Struktura: SerbianMandateReject 

• Koristi se za odbijanje instrukcija za evidentiranje, izmenu i povlačenje Mandata, pri čemu element 
OriginalMessageName ima vrednost tipa instrukciie koia se odbiia (mndt.001.001.01 ili 
mndt.002.001.01) 

• Generišu je i ispostavljaju banke koje koriste dodatni servis vođenja Registra mandata, odnosno 
Procesor na osnovu izvršenih kontrola. 
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Index 

Kardin 

alnost 

Element poruke 

Tip 

Opis i poslovna 
pravila 

1.0 

M 1 

+ 

Header 

GroupHeader2 

Zaglavlje poruke 

1.1 

M 1 

+ 

+ 

Messageld 

Max35Text 

Jedinstveni 

identifikator poruke 

koji formira pošiljalac 
poruke 

1.2 

M 1 

+ 

+ 

CreationDate 

ISODateTime 

Datum kreiranja 

poruke 

1.7 

M 1 

+ 

+ 

InstructingAgent 

Financial 

Institution2 

Pošiljalac poruke 

1.7 

М 1 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija 

pošiljaocaporuke 

1.7 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC pošiljaoca poruke 

1.8 

М 1 

+ 

+ 

InstructedAgent 

Financial 

Institution2 

Primalac poruke 

1.8 

М 1 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija primaoca 
poruke 

1.8 

М 1 

+ 

+ 

+ 


3ICAgent 

BlCIdentifier 

BIC primaoca poruke 

3.0 

М 1-n 

+ 

Transactionlnformation 

Transaction 

Information 

Telo poruke 

instrukcije odbijanja 
(Reject) 

3.1 

М 1 

+ 

+ 

Transactionld 

Max35Text 

Jedinstveni Id 

transakcije podnosioca 
instrukcije 

3.2 

М 1 

+ 

+ 

OriginalT ransactionlnformation 

Orgina lTtansaction 
Information 

Identifikacija originalne 
poruke 

3.3 

М 1 

+ 

+ 

+ 

OriginalMessageld 

Max35Text 

Jedinstveni 

identifikator originalne 
poruke 

3.4 

М 1 

+ 

+ 

+ 

OriginalMessageName 

Max35Text 

Naziv originalne 

poruke 

(mndt .ххх.ххх.хх). 

3.5 

М 1 

+ 

+ 

OriginalTransactionld 

Max35Text 

Id originalne instrukcije 

3.6 

М 1 

+ 

+ 

TransactionStatus 

T rnsactonlndividual 
Status2Code 

Vrednost: RJCT 

3.7 

М 1 

+ 

+ 

StatusReasonlnformation 

StatusReason 

Information4 

Informacije o 

razlozima odbijanja 

3.8 

М 1 

+ 

+ 

+ 

StatusOriginator 

Party 

ldentificationl4 

Identifikacija inicijatora 
odbijanja instrukcije 

(banke ili ugovorne 
strane) 

3.8 

М 1 

+ 

+ 

+ 

+ 

Originatorld 

Financial 

Institution3 

Identifikacija 
inicijatora odbijanja 

instrukcije (banke) 

3.8 

М 1 

+ 

+ 

+ 

+ 

+ 

Originator 

F inanciallnstitution 
Identification4 

Identifikacija 
inicijatora odbijanja 

instrukcije (banke) 

3.8 

М 1 

+ 

+ 

+ 

+ 

+ 

+ BlCOriginator 

BlCIdentifier 

BIC banke, inicijatora 
odbijanja instrukcije 

3.8 

М 1 

+ 

+ 

+ 

+ 

OriginatorName 

Max35Text 

Naziv inicijatora 

odbijanje instrukcije 

3.9 

М 1 

+ 

+ 

+ 

StatusReason 

ReturnReason3 

Choice 

Kodirani razlog za 
odbijanje instrukcije 

3.10 

М 1 

+ 

+ 

+ 

+ 

StatusCode 

T ransactionReturn 
Reason5Code 

Kod razloga za odbijanje 
instrukcije 

3.12 

0 0-1 

+ 

+ 

+ 

AdditionalReasonlnformation 

Maxl05Text 

Dodatno obrazloženje 
za odbijanje 

instrukcije. 
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Specifikacija ISO kodova za Reject transakcije: 


ISO kod 

Opis 

AC01 

Pogrešan broj računa 

AC04 

Račun zatvoren 

AC06 

Račun blokiran 

AG01 

Transakcija zabranjena 

AG02 

Pogrešan kod banke 

AM01 

Nula iznos 

AM02 

Nedopušten račun 

AM03 

Pogrešna valuta 

AM04 

Nedovoljno sredstava 

AM05 

Dupliran nalog 

AM06 

Premali iznos 

AM07 

Blokiran iznos 

AM09 

Pogrešan iznos 

AM10 

Pogrešna kontrolna suma 

BE01 

Nesaglasan krajnji korisnik 

BE04 

Pogrešna adresa poverioca 

BE05 

Neprepoznat poverilac 

BE06 

Neprepoznat dužnik 


ISO kod 

Opis 

BE07 

Pogrešna adresa dužnika 

DT01 

Pogrešan datum 

ED01 

Ne postoji korespodentna banka 

ED03 

Traženo stanje 

MD01 

Nema validnog mandata 

MD02 

Pogrešne informacije o mandatu 

MD03 

Pogrešan format podatka o razlozima 

MD04 

Pogrešan format podataka za indikatore 

MD06 

Dužnik je podneo Refunda zahtev 

MD07 

Dužnikje umro 

MS02 

Nije naveden razlog od strane dužnika 

MS03 

Nije naveden razlog od strane banke 

NARR 

Opisno 

RC01 

Pogrešan identifikator banke 

RF01 

Referenca transakcije nije jedinstvena 

TM01 

Cutt off time (istek vremena) 

ED05 

Greška u obračunu 

RR01 

Razlozi regulatora (procesora) 


PORUKA paos.004.001.01 REQUEST&CANCELLATION 
Struktura: SerbianCancel 

• Koristi se za povlačenje instrukcija za evidentiranje, izmenu i povlačenje Mandata, pri čemu element 
OriginalMessageName ima vrednost tipa instrukcije koja se povlači. 

• Generišu je i ispostavljaju Procesoru banke koje koriste dodatni servis vođenja Registra mandata, pre 
realizacije instrukcije koja se povlači. 


Index 

Kardin 

alnost 

Element poruke 

Tip 

Opis 

1.0 

M 1 

+ 

Header 

GroupHeader 

Zaglavlje poruke 

1.1 

M 1 

+ 

+ 

Messageld 

Max35Text 

Jedinstveni identifikator 
poruke koji formira 
pošiljalac poruke 

1.2 

M 1 

+ 

+ 

CreationDate 

ISODateTime 

Datum kreiranja poruke 

1.3 

M 1 

+ 

+ 

InstructingAgent 

Financiai 

Institution2 

Pošiljalac poruke 

1.3 

М 1 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija pošiljaoca 
poruke 

1.3 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC pošiljaoca poruke 

1.4 

М 1 

+ 

+ 

InstructedAgent 

Financial 

Institution2 

Primalac poruke 

1.4 

М 1 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija primaoca 
poruke 

1.4 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC primaoca poruke 

2.0 

М 1-n 

+ 

Т ransactionlnformation 

Transaction 

Information 

Telo poruke za 

povlačenje poruke iii 
pojedinačne instrukcije 

2.1 

М 1 

+ 

+ 

Transactionld 

Max35Text 

Jedinstveni Id 

transakcije podnosioca 
instrukcije 

2.2 

М 1 

+ 

+ 

OriginalT ransactionlnformation 

OriginalGroup 

Information2 

Identifikacija originalne 
poruke 

2.3 

М 1 

+ 

+ 

+ 

OriginalMessageld 

Max35Text 

Jedinstveni identifikator 
originalne poruke 

2.4 

М 1 

+ 

+ 

+ 

OriginalMessageName 

Max35Text 

Naziv originalne 

poruke. 
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2.5 

0 0-1 

+ 

+ 

+ OriginalCreationDate 

ISODateTime 

Datum kreiranja 

originalne poruke 

2.6 

0 0-n 

+ 

+ 

OriginalT ransactionld 

Max35Text 

Id transakcije banke 
podnosioca instrukcije iz 
originalne instrukcije 

2.7 

M 1 

+ 

+ 

TransactionStatus 

Trnsactonlndividual 

Status2Code 

Vrednost: CNCL 


PORUKA mndt.004.001.01 MANDATE QUERY 
Struktura: SerbianMandateQuery 

• Koristi se za ispostavljanje zahteva za dobijanjem informacija o mandatu evidentiranih u Registru 
mandata. 

• Generišu je i ispostavljaju Procesoru banke koje koriste dodatni servis vođenja Registra mandata. 


Index 

Kardin 

alnost 

Element poruke 

Tip 

Opis 

1.0 

M 1 

+ 

Header 

GroupHeader 

Zaglavlje poruke 

1.1 

M 1 

+ 

+ 

Messageld 

Max35Text 

Jedinstveni identifikator 
poruke koji formira 
pošiljalac poruke 

1.2 

M 1 

+ 

+ 

CreationDate 

ISODateTime 

Datum kreiranja poruke 

1.3 

M 1 

+ 

+ 

InstructingAgent 

Financiallnstitutionž 

Pošiljalac poruke 

1.3 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

Identification4 

Identifikacija pošiljaoca 
poruke 

1.3 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCIdentifier 

BIC pošiljaoca poruke 

1.4 

М 1 

+ 

+ 

InstructedAgent 

FinanciaIInstitution2 

Primalac poruke 

1.4 

М 1 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija primaoca 
poruke 

1.4 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC primaoca poruke 

2.0 

М 1 

+ 

Transactionlnformation 

Transaction 

Information 

Telo poruke za upit u 
Registar mandata 

2.1 

М 1 

+ 

+ 

Transactionld 

Max35Text 

Jedinstveni identifikator 
upita 

2.2 

0 0-n 

+ 

+ 

Mandate 

Mandateldentification 

Identifikacija mandata 
ili aneksa 

Upit za dati mandat ili 
aneks 

2.2 

0 0-1 

+ 

+ 

+ 

Mandatld 

Max35Text 

Identifikacija mandata ili 
aneksa 

2.2 

0 0-1 

+ 

+ 

+ 

Amendmentlndicator 

T rueF alselndicator 

Indikator aneksa 

2.3 

OO-l 

+ 

+ 

MandateStatus 

Mandatelndividual 

Status2Code 

Status mandata 

Upit po statusu mandata 

2.4 

О 0-n 

+ 

+ 

Creditor 

Partyldentification 13 

Poverilac 

Upit po poveriocu 

2.4 

OO-l 

+ 

+ 

+ 

Debtorld 

Max35Text 

Id dužnika, matični broj ili 
Jmbg 

2.4 

OO-l 

+ 

+ 

+ 

Name 

Max70Text 

Ime poverioca 

2.5 

О 0-n 

+ 

+ 

CreditorAccount 

CashAccount8 

Broj računa poverioca 

Upit po broju računa 
poverioca 

2.5 

OO-l 

+ 

+ 

+ 

Accountld 

Account 

ldentification2 

Identifikacija računa 

poverioca 

2.5 

OO-l 

+ 

+ 

+ 

+ 

IBANAccount 

IBANldentifier 

IBAN broj računa 

poverioca 

2.6 

О 0-n 

+ 

+ 

CreditorAgent 

FinancialInstitution3 

Banka poverioca 

Upit po banci poverioca 

2.6 

OO-l 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

Identification5 

Identifikacija banke 

poverioca 

2.6 

OO-l 

+ 

+ 

+ 

+ 

BICAgent 

BIC Identifier 

BIC banke poverioca 
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2. 7 

0 0-n 

+ 

+ 

Debtor 

PartyIdentificationl9 

Dužnika 

Upit po dužniku 

2.7 

0 0-1 

+ 

+ 

+ 

Debtorld 

Max35Text 

Id dužnika, matični broj ili 
Jmbg 

2.7 

0 0-1 

+ 

+ 

+ 

Name 

Max70Text 

Ime dužnika 

2.8 

O 0-n 

+ 

+ 

DebtorAccount 

CashAccount8 

Broj računa dužnika 

Upit po računu dužnika 

2.8 

OO-l 

+ 

+ 

+ 

Accountld 

Account 

ldentification2 

Identifikacija računa 

dužnika 

2.8 

OO-l 

+ 

+ 

+ 

+ 

IBANAccount 

IBANldentifier 

IBAN broj računa 

dužnika 

2.9 

O 0-n 

+ 

+ 

DebtorAgent 

FinancialInstitution3 

Banka dužnika 

Upit po banci dužnika 

2.9 

OO-l 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

Identification5 

Identifikacija banke 

dužnika 

2.9 

OO-l 

+ 

+ 

+ 

+ 

BICAgent 

BIC Identifier 

BIC banke dužnika 


PORUKA mndt.005.001.01 MANDATE RESPONSE 
Struktura: SerbianMandateResponse 

• Koristi se za davanje odgovora na podneti zahtev za dobijanjem informacija o mandatu evidentiranih 
u Registru mandata. 

• Generišu ih i ispostavljaju Procesoru, banke koje koriste dodatni servis vođenja Registra mandata i 
koje su podnele zahtev za dobijanjem informacija o mandatu . 


Index 

Kardin 

alnost 

Element poruke 

Tip 

Opis 

1.0 

M 1 

+ 

Header 

GroupHeader 

Zaglavlje poruke 

1.1 

M 1 

+ 

+ 

Messageld 

Max35Text 

Jedinstveni 

identifikator poruke 
koji formira pošiljalac 
poruke 

1.2 

M 1 

+ 

+ 

CreationDate 

ISODateTime 

Datum kreiranja 

poruke 

1.3 

M 1 

+ 

+ 

InstructingAgent 

Financiai 

Institution2 

Pošiljalac poruke 

1.3 

М 1 

+ 

+ 

+ 

Agentld 

Financiallnstitution 

Identification4 

Identifikacija 
pošiljaoca poruke 

1.3 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCldentifier 

BIC pošiljaoca poruke 

1.4 

М 1 

+ 

+ 

InstructedAgent 

Financiai 

Institution2 

Primalac poruke 

1.4 

М 1 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija 
primaoca poruke 

1.4 

М 1 

+ 

+ 

+ 

+ 

BICAgent 

BlCIdentifier 

BIC primaoca poruke 

2.0 

М 1 

+ 

Т ransactionlnformation 

Transaction 

Information 

Odgovor na 

postavljeni upit 

2.1 

М 1 

+ 

+ 

Transactionld 

Max35Text 

Jedinstveni 

identifikator odgovora 
na upit 

2.2 

М 1 

+ 

+ 

OriginalT ransactionld 

Max35Text 

Id transakcije 

podnosioca upita iz 
originalne instrukcije 

2.3 

OO-n 

+ 

+ 

QueryResponse 

QueryAndResponse 

Odgovor na upit 

2.4 

М 1 

+ 

+ 

+ 

MandateStatus 

Mandatelndividual 

Status2Code 

Status mandata iz 

internog šifarnika 

Procesora 

2.5 

М 1 

+ 

+ 

+ 

Mandatlnformation 

Mandate 

Information3 

Informacije o 

mandatu 

2.6 

OO-l 

+ 

+ 

+ 

+ 

Contractld 

Max35Text 

Broj ugovora po kome 
je izdat mandat 
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2.10 

M 1 

+ 

+ 

+ 

+ 

MandateType 

MandateType 

lnformation8 

Tip mandata 

2.11 

M 1 

+ 

+ 

+ 

+ 

+ 

SequenceType 

SequenceT уре 1 Code 

Vrednosti: RECR, 

ONEO 

2.22 

M 1 

+ 

+ 

+ 

+ 

Mandatld 

Max35Text 

Identifikacija mandata 
ili aneksa 

2.23 

M 1 

+ 

+ 

+ 

+ 

DateSignature 

ISODate 

Datum potpisivanja 
mandata ili aneksa 

2.24 

М 1 

+ 

+ 

+ 

+ 

Amendmentlndicator 

T rueF alselndicator 

Indikator aneksa 

(izmena mandata) 

2.25 

0 0-1 

+ 

+ 

+ 

+ 

Amendmentlnformation 

Amndmntlnformation 

Details4 

Informacije o 

osnovnom mandatu 

2.26 

0 0-1 

+ 

+ 

+ 

+ 

+ 

OrgMandateld 

Max35Text 

Identifikator 
osnovnog mandata 

2.43 

М 1 

+ 

+ 

+ 

Creditor 

Party 

Identificationl3 

Poverilac 

2.43 

М 1 

+ 

+ 

+ 

+ 

Debtorld 

Max35Text 

Id dužnika, matični 
broj ili Jmbg 

2.43 

М 1 

+ 

+ 

+ 

+ 

Name 

Max70Text 

Ime poverioca 

2.43 

0 0-1 

+ 

+ 

+ 

+ 

PostAddress 

PostalAddress4 

Poštanska adresa 

poverioca 

2.43 

0 0-5 

+ 

+ 

+ 

+ 

+ 

Address 

Max70Text 

Adresa poverioca 

2.43 

М 1 

+ 

+ 

+ 

+ 

+ 

CountryCode 

CountryCode 

Kod države poverioca 

2.44 

М 1 

+ 

+ 

+ 

CreditorAccount 

CashAccount8 

Broj računa poverioca 

2.44 

М 1 

+ 

+ 

+ 

+ 

Accountld 

Account 

ldentification2 

Identifikacija računa 
poverioca 

2.44 

М 1 

+ 

+ 

+ 

+ 

+ 

IBANAccount 

IBANIdentifier 

IBAN broj računa 
poverioca 

2.45 

М 1 

+ 

+ 

+ 

CreditorAgent 

FinancialInstitution2 

Banka poverioca 

2.45 

М 1 

+ 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija banke 

poverioca 

2.43 

М 1 

+ 

+ 

+ 

+ 

+ 

BICAgent 

BIC Identifier 

BIC banke poverioca 

2.57 

М 1 

+ 

+ 

+ 

Debtor 

Party 

IdentifIcationl9 

Dužnika 

2.57 

М 1 

+ 

+ 

+ 

+ 

Debtorld 

Max35Text 

Id dužnika, matični 
broj ili Jmbg 

2.57 

М 1 

+ 

+ 

+ 

+ 

Name 

Max70Text 

Ime dužnika 

2.57 

0 0-1 

+ 

+ 

+ 

+ 

PostAddress 

PostalAddress4 

Poštanska adresa 

dužnika 

2.57 

0 0-5 

+ 

+ 

+ 

+ 

+ 

Address 

Max70Text 

Adresa dužnika 

2.57 

М 1 

+ 

+ 

+ 

+ 

+ 

CountryCode 

CountryCode 

Kod države dužnika 

2.58 

М 1 

+ 

+ 

+ 

DebtorAccount 

CashAccount8 

Broj računa dužnika 

2.58 

М 1 

+ 

+ 

+ 

+ 

Accountld 

Account 

ldentification2 

Identifikacija računa 
dužnika 

2.58 

М 1 

+ 

+ 

+ 

+ 

+ 

IBANAccount 

IBANIdentifier 

IBAN broj računa 
dužnika 

2.59 

М 1 

+ 

+ 

+ 

DebtorAgent 

FinancialInstitution2 

Banka dužnika 

2.59 

М 1 

+ 

+ 

+ 

+ 

Agentld 

F inanciallnstitution 
Identification4 

Identifikacija banke 

dužnika 

2.59 

М 1 

+ 

+ 

+ 

+ 

+ 

BICAgent 

BIC Identifier 

BIC banke dužnika 

2.81 

0 0-1 

+ 

+ 

+ 

Remmitancelnformation 

Remittance 

Information3 

Informacije o 

plaćanju 

2.82 

0 0-n 

+ 

+ 

+ 

+ 

U nstructuredRemmitance 

Maxl40Text 

Nestruktuirane 
informacije o plaćanju 

2.83 

М 1 

+ 

+ 

+ 

+ 

StructuredRemmitance 

StructuredRemittance 

Informationć 

Struktuirane 
informacije o plaćanju 

2.84 

М 1 

+ 

+ 

+ 

+ 

+ 

FirstCollectionDate 

ISODate 

Datum kada može da 
bude realizovana prvo 
zaduženje 
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2.85 

0 0-1 

+ 

+ 

+ 

+ 

+ 

FinalCollectionDate 

ISODate 

Datum do koga može 
da bude izvršavana 
poslednje zaduženje 

2.86 

M 1 

+ 

+ 

+ 

+ 

+ 

NumberOfCollection 

Мах 15N umericT ext 

Maksimalni bro 

obaveza po mandatu 

2.87 

M 1 

+ 

+ 

+ 

+ 

+ 

TotalAmount 

EuroMax9Amount 

Ukupan iznos 

zaduženja po mandatu. 

2.87 

M 1 

+ 

+ 

+ 

+ 

+ 

+ 

Amount 

Decimal, 9,2 

Ukupan iznos 

plaćanja. 

2.87 

M 1 

+ 

+ 

+ 

+ 

+ 

+ 

CurrencyCode 

EuroCurrencyCode 

Kod valute 

2.88 

0 0-1 

+ 

+ 

+ 

+ 

+ 

Frequency Metric 

FrequencyMetric 

Metrika dospeća 

2.88 

М 1 

+ 

+ 

+ 

+ 

+ 

+ 

Frequency Code 

FrequencyCode 

Kodirana metrika 

dospeća: 

DAIL, za dan, 

MNTH, za mesec 
YEAR, za godinu 

2.88 

М 1 

+ 

+ 

+ 

+ 

+ 

+ 

Periodic 

Мах 15NumericT ext 

Periodika dospeća u 
datoj metrici 

2.89 

0 0-n 

+ 

+ 

+ 

+ 

+ 

FixedReqDate 

ISODate 

Fiksni datumi dospeća 
(DueDate) 

2.90 

0 0-1 

+ 

+ 

+ 

+ 

+ 

Tolerancy 

Tolerancy 

Period tolerancije 

dospeća u danima 

2.91 

М 1 

+ 

+ 

+ 

+ 

+ 

+ 

TolerancySign 

TolerancySign 

Kodirani znak perioda 
tolerancije: 

PLS, po dospeću 
(PLUS) 

MNS, pre dospeća 
(MINUS) 

BTH, pre i posle 
dospeća (BOTH) 

2.91 

М 1 

+ 

+ 

+ 

+ 

+ 

+ 

TolerancyValue 

Мах 15N umericT ext 

Broj dana tolerancije u 
dospeću 

2.92 

0 0-1 

+ 

+ 

+ 

+ 

+ 

DebitAmount 

EuroMax9Amount 

Maksimalni iznos u 
jednom nalogu 

zaduženja (collection) 

2.92 

М 1 

+ 

+ 

+ 

+ 

+ 

+ 

Amount 

Decimal, 9,2 

Iznos plaćanja. 

2.92 

М 1 

+ 

+ 

+ 

+ 

+ 

+ 

CurrencyCode 

EuroCurrencyC ode 

Kod valute 

2.93 

0 0-1 

+ 

+ 

+ 

+ 

+ 

Exchange 

Exchange 

Valutni uslovi plaćanja 

2.93 

М 1 

+ 

+ 

+ 

+ 

+ 

+ 

CurrencyCode 

CurrencyCode 

Kod valute plaćanja 

2.93 

М 1 

+ 

+ 

+ 

+ 

+ 

+ 

ExchangeRate 

BaseOnRate 

Kurs ugovorene valute: 
SEL- prodajnikurs 
MID - srednji kurs 
BUY - kupovni kurs 

2.93 

М 1 

+ 

+ 

+ 

+ 

+ 

+ 

Exchange list 

BaseOnList 

Vrednosti : 

NBS - za kursnu listu 
Narodne banke 

BANK - za kursnu 
listu banke (nije osnov 
za kontrolu Procesora) 

2.97 

0 0-1 

+ 

+ 

+ 

+ 

+ 

CreditorReference 

CreditorReference 

Informationl 

Identifikator dužnika 

2.97 

0 0-1 

+ 

+ 

+ 

+ 

+ 

+ 

ReferenceType 

CreditorReference 

Typel 

Referenca 

2.97 

0 0-1 

+ 

+ 

+ 

+ 

+ 

+ 

+ Purport 

Max35Text 

Poziv na broj dužnika 

2.10 

0 0-1 

+ 

+ 

+ 

+ 

+ 

AdditionalRemitance 

Maxl40Text 

Dodatne informacije o 
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PORUKA OMOTNICA ZA PORUKE SOPSTVENOG FORMATA 
SWIFT PORUKA MT998 KAO OMOTNICA 

Struktura: SWIFT poruka MT998 

• Koristi se kao omotnica za poruke sopstvenog formata u sistemu Narodne banke Srbije 
Raspored elemenata: 


Polje 

Element poruke 

Obavezno 

Napomena 

20 

Referenca poruke 

Da 

TRN 

12 

Podtip poruke 

Da 

Podtip poruke 

77E 

Sadržaj omotnice poruke koji odgovara 
navedenom podtipu poruke sopstvenog 
formata 

Da 

U sistemu Narodne banke Srvije sadržaj 
omotnice u poruci sopstvenog formata 
čine samo unapred standardizovana 
polja 

59A 

BIC primaoca 

Da 


54A 

BIC pošiljaoca 



21 

Povezana referenca 




Ostala polja po SWIFT standardu 
ukoliko se koriste u konkretnoj poruci 
sopstvenog formata 



79 

Polja sopstvenog formata 


U prvom redu obavezno samo crtica, 
polja sopstvenog formata nemaju dve 
tačke na početku 


Napomena: Poslovna pravila su definisana od strane Narodne banka Srbije. 


PORUKA SMT710 SOPSTVENOG FORMATA 

Struktura: Poruka sopstvenog formata u sistemu Narodne banke Srbije 

• Koristi se za obaveštenje Službe za prinudnu naplatu o nerealizovanom osnovu (mandatu) i prenos 
podataka o osnovu za blokiranje računa dužnika sa zadatim matičnim brojem. 

• Generišu ih i ispostavljaju Procesor u slučaju da je instrukcija direktnog zaduženja odbijena od strane 
banke dužnika zbog blokade računa dužnika i/ili nedostatka raspoloživih sredstava za realizaciju 
zaduženja. 

Raspored elemenata u polju :79 omotnice MT998: 


Polje 

Element poruke 

Obavezno 

Napomena 

71010: 

Broj računa (počinje ,,slešom“) 


Broj računa na koji glasi blokada 

71020: 

Naziv računa 


Naziv računa na koji glasi blokada 
(ukoliko je poznat), max. 35 karaktera 

71030: 

Matični broj vlasnika računa 

da 

Obavezno, s obzirom da se blokada vrši po 
matićnom broju dužnika 

71040: 

Poreski identifikacioni broj 

vlasnika (PIB) 

da 

Obavezno 

71051: 

Tip dokumenta 

da 

02 - hartije od vrednosti 

03 - ostali osnovi 

71052: 

Datum i vreme prijema 

da 

U formatu: YYMMDD HH:MM:SS 

71053: 

Datum dospeća 

da 

U formatu: YYMMDD 

71054: 

Prioritet 

da 

01 do 10 

71056: 

Iznos za izvršenje (nenaplaćeni 
iznos), odnosno zabranu 

raspolaganja 

da 


71059: 

Broj sa dokumenta, sudski broj 
rešenja 

da 

Мах. 35 karaktera 


Podaci o blokadi, polja iz poruke 
MT103 (57A, 59, 70 i 72) koja 
treba da se izvrši da bi prinudna 
naplata bila sprovedena 


Polja su označena sa 57A:, 59:, 70: i 72: 

57A: 

Račun i BIC banke čiji se račun 
odobrava (u kojoj je korisnikov 
račun) u formatu: 

/С /račun banke ili /račun banke 

da 

Mora da se slaže sa vodećim brojem 
računa u tagu 59. 

Kose crte i scovo C su deo sintakse 
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BIC 



59: 

Bez opcija 
/račun korisnika 
naziv i adresa 

da 

Račun je obavezan, a kosa crta je deo 
sintakse za označavanje računa 

70: 

Šifra plaćanja, poziv na broj 
zaduženja i poziv na broj 
odobrenja. 

Elementi se označavaju 

prefiksima koji su crticama 
odvojeni od sadržaja 

Pozivi na broj imaju sa leve strane 
pridružene odgovarajuće modele, 
tako da ukupna dužna ne prelazi 
22 karaktera: 

SIF-(šifra plaćanja) 

PBZ-(poziv na broj zaduženja) 
PBO-(poziv na broj odobrenja) 

Da 

Primer: 

:70:SIF-111 

PBZ-97123456ABC 

PBO-97123AFG14 

REF-456789 

72: 

Svrha plaćanja, do 105 karaktera 

U prvom redu /BNF/, a u ostalim 
redovima // 

Najviše 4 reda 

da 

Primer: 

:72:/BNF/UPLATA PO 
//FAKTURI 123AFG14, 

//RAZLIKA ZA MAJ 

71070: 

Ukoliko je zabranjeno 

raspolaganje - datum do koga je 
zabranjeno ili reč TRAJNO 
ukoliko nije oročeno, a prazno 
ukoliko je u pitanju prinudna 
naplata 



71090: 

Datum promene 

da 

U formatu: YYMMDD 
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Prilog 7: 

Ispunjenost regulative evropskog saveta za plaćanja 

Sistem ispunjava zakonsku regulativu propisanu od strane evropskog saveta za plaćanja 
EPC ako je u skladu sa sledećim: 


R.Br. 

Tekst 

1. Uvodjenje/Izmena 
zakonskog okvira 

Evropski parlament pozdravlja inicijativu Komisije da ustanovi zakonske 
preduslove za uspostavljanje zone sa jedinstvenim sistemom plaćanja u radu sa 
stanovništvom; naznačava, međutim, da nacionalna pravila moraju da budu 
formulisana na takav način da ne ugrožavaju efikasnost nacionalnih sistema i 
procedura. 

2. Instrumenti plaćanja 

Uzima u obzir da je neophodno obezbediti paket praktičnih, povoljnih, 
postojanih i predvidljivih načina plaćanja. 

3. Upoznavanje sa 

budućim slučajevima 

korišćenja 

Zahteva od komisije da (što ranije / pre svega ) sačini ekonomsku studiju kroz 
koju se sagledava i razjašnjava koliki je ulog, i koje mogućnosti mogu da budu 
odabrane, imajući u vidu, pored ostalog, infrastrukturu, međupovezanost i inter- 
hankarstvo. 

4. Ograničenja lokalnih 
regulativa 

Razmatra se, imajući u vidu da je trenutna situacija u evropskoj platnoj sferi 
nezadovoljavajuća, da se na tehničkom nivou preduzmu neophodne zakonske 
mere da bi se uspostavio efikasan i efektan evropski platni sistem. 

5. Transparentnost 

zahtevanog sistema 

Ostaje pri tom, da iz gore navedenog proizilazi da institucije Unije treba da 
jasno predstave svoje namere i plan (raspored) implementacije, kao i da 
privredni deoničari treba da nadgledaju implementaciju. 

6. Usitnjavanje i 

ukrupnjavanje 

Zauzima stav da dobri poslovni običaji i pravila koja uređuju rad institucija koje 
pružaju platne usluge treba da budu sačinjena uniformnije na evropskom nivou 
u cilju obezbeđenja uslova za ravnopravnu konkurenciju; zauzima stav da dalje 
usitnjavanje regulative o dobrim poslovnim običajima ili samanjenje standarda 
kojim isti podležu, mora da bude sprečeno; zauzima stav da u interesu svih 
zainteresovanih strana (potrošači, trgovci, i banke), novi status institucija koje 
pružaju platne usluge ne sme da dovde do pogoršanja u fizičkoj, osmišljenoj, 
finansijskoj i ekonomskoj sigumosti sredstava plaćanja, prisutnih na tržištu. 

7. Monopolizam 

Poziva komisiju da pomno prati trendove koncentracije među ponuđačima 
platežnih usluga; primetno je da u nekim oblastima, na pr. Kreditnih kartica, 
tržištem dominira manji broj preduzeća; nameće se stav da pmžanje platežnih 
usluga (transferi novca, sredstva prekoračenja) zahteva visok nivo stručnosti i 
odgovomosti u odnosu na potrošače, što upućuje na to da platežne usluge 
stanovništvu mogu da pružaju isključivo službeno nadzirane fmne. 

8. Propisana pravila u 
sistemu 

Pozdravlja namem komisije da uključi sva spoljna i unutrašnja plaćanja u 
zakonski okvir; predlaže da se okvir zakonskog delokmga od 2006-te proširi na 
sva plaćanja unutar EU do iznosa od 50000 EUR; poziva na jedinstvena pravila 
za regulisanje transakcija koje se izvršavaju u dmgim evropskim valutama. 

9. Sigurnost 

Smatra da je neophodno promovisati zakonsku postojanost i tehničku sigurnost 
plaćanja u evro zoni, imajući u vidu da potrošači s pravom očekuju da će u istoj 
meri biti zaštićeni na unutrašnjem tržištu kao što su to u njihovim matičnim 
državama. 

10. 11. Inovacije 

Pozdravlja namere Evropske bankarske industrije kao i Komisije, da se 
uspostavi pan-evropska direktno-debitna šema. 

Ostaje pri stavu da, u pogledu sektora bankovnih kartica, u kojem je 
prekogranična delatnost vrlo zadovoljavajuća, jedan od prioriteta treba da bude i 
uvođenje nove generacije smart kartica, i to u potpunosti i bez kašnjenja, u cilju 
obezbeđenja veće sigumosti pomenutih kartica na celovitom podmčju Unije. 

12. Izveštavanje 

Smatra za neophodno da se najbitnije informacije bankovnim klijentima pmžaju 
na sažet i lako razumljiv način, ocenjujući pri tom da su, od strane Unije 
predloženi kompleksni zahtevi u pmžanju informacija i da su kao takvi trenutno 
preobimni i nepraktični. 

13. Komunikacioni kanali 

Imajući u vidu da je potrošačka mobilnost u suštinskom interesu zdrave 
konkurencije; poziva Bankarsku industriju da podnese predloge za 
standardizovanu razmenu podataka (na pr: poslovnici, direktna zaduženja) u 
cilju olakšanja procedure premeštanja klijentskih računa (naloga); odbacuje 
evropske odredbe o maksimalnoj naknadi za zatvaranje računa (naloga) i 
insistira na potpunoj transparentnosti kada su u pitanju ovakve naknade. 
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14.17.18. Životni ciklusi 

Zagovara, u interesu zakonske postojanosti i materijalno povoljnog procesiranja 
platnih naloga, mogućnost rane neopozivosti (na pr: pre nego što je transfer 
inicijalizovan) platnih naloga koji su direktno upućeni entitetu za pružanje 
platnih usluga (na pr: transferi); predlaže takvo rešenje za slučajeve direktnog 
debitnog plaćanja, da postoji mogućnost da se isti opozovu u dužem periodu, pre 
svega kada iznos koji treba platiti iz bilo kojih razloga ne može da bude 
naznačen u vreme izdavanja platnog naloga. 

Odbacuje preporuke da se lično učešće klijenata ograniči na EUR 150 u 
slučajevima neovlašćenih transakcija (na pr: ukradena kreditna kartica), i to 
kada klijenti nisu ispunili svoju obavezu da o tome pruže obaveštenje; insistira 
se, radije, na ohrabrivanju lične odgovomosti klijenata, kao i da je potrebno 
obezbediti takva rešenja koja bi omogućila blokiranje platnih kartica na 
celokupnoj teritoriji EU, putem jedinstvenog telefonskog broja. 

Zagovara rešenje da se zakonskim okvirom ustoliči princip po kojem bi, 
bez obzira na korišćeni način plaćanja, celokupan iznos naznačen u 
platnom nalogu bio prebačen na račun (nalog) primaoca, bez ikakvih 
odbitaka, sem ukoliko primalac nije eksplicitno postigao drugačiji 
sporazum sa svojom bankom, u kom slučaju, iznos i tip odbitka treba da 
budejasno naznačen primaocu. 

15. Razgraničenje 

odgovornosti 

Pozdravlja stremljenja u promovisanju trgovine na distancu i Internet prodaje; 
odbacuje odgovomost institucija koje obezbeđuju platne usluge, u slučajevima 
sporova između prodavaca i kupaca, međutim, ipak radije insistira na jasnom 
razgraničenju između bazičnih transakcija i plaćanja, bilo kroz postulate 
odgovomosti ili pak kroz proširenje klijentskog prava opoziva; smatra da razvoj 
(opcionalnih) sigumosnih sistema (na pr: kroz namenske račune) treba prepustiti 
samom tržištu. 

16. Sledljivost 

Smatra da institucija koja obezbeđuje platne usluge treba da bude odgovoma za 
tačno i pravovremeno izvršenje platnih naloga kako je to regulisano državnim 
zakonima zemalja članica, kao i da bude obavezna da to i dokaže, već čim se 
klijentski platni nalog nađe u njenom posedu; odbacuje bilo kakvo proširenje 
stroge odgovornosti; mišljenja je, ipak, da u okviru zakonskog odnosa sa 
klijentom, a u pogledu grešaka u selekciji, odgovomost pomenute institucije 
treba proširiti i na druge firme u lancu kao i na tehničke kapacitete koje koristi; 
predlaže da kroz internu regulativu, bankovne asocijacije, mrežne operatere i 
trgovce usvoji proceduru za pravovremeno razjašnjenje pitanja inteme 
odgovomosti; smatra da procenjivanje odgovomosti u vezi sa posledičnim 
štetama i višom silom treba da bude prepušteno nacionalnim jurisdikcijama. 

19. Fleksibilnost 

Pozdravlja predlog Komisije, u pogledu Specijalne Prepomke VII, da se EU 
definiše kao integrisani zakonski okvir; zauzima stav, međutim, da granične 
vrednosti moraju da budu uvedene za gotovinske transfere; primećuje da je 
tehnički neizvodljivo sačiniti efektne rizik-orjentisane procedure za 
identifikaciju transfera kojima nedostaju podaci o poreklu inicijalizatora. 

20. Upoznavanje sa 

rizicima 

Podstiče bankarsku industriju da kontinuirano unapređuje bezbednost 
on-line bankarstva, u saradnji sa sektorom informacionih tehnologija i 
nadzornim vlastima, kao i da klijentima pruži smislene i razumljive 
informaciie o potencijalnim rizicima i neophodnoj predostrožnosti. 

21. Poravnanje 

Pozdravlja sve pokušaje alternativnog rešenja sporova koji mogu da 
doprinesu izbegavanju dugotrajnih parnica; smatra da ukoliko se putem 
dobrovoljne rasprave sporovi ipak ne razreše u razumnom vremenu, kao 
i da se ne može obezbediti efektna žalbena procedura ili obeštećenje za 
klijente, bude neophodno da se rešenje sporova obavezno obavlja u 
okviru zemalja članica, kao i na evropskom nivou; 
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Prilog 8: 

Ekonomska opravdanost uvođenja platnog sistema 


Uporedna tabela sa procenom prihoda platnog sistema u odnosu na broj procesiranih 
poruka u toku jedne godine prema broju poruka i broju transakcija u prvoj vrsti 
objavljenih od strane Udruženja banaka Srbije na bankarskom skupu Banklnfo 2012 na 
Paliću: 


ВТ х 1.8 RSD 

€ 

17.124.645,60 

214.058,07 

171.246.456,00 

2.140.580,70 

342.492.912,00 

4.281.161,40 

856.232.280,00 

10.702.903,50 


BP х 1.8 RSD 

€ 

843.087,60 

10.538,60 

8.430.876,00 

105.385,95 

16.861.752,00 

210.771,90 

42.154.380,00 

526.929,75 



Broj poruka (BP) 

Broj transakcija (BT) 

X 1 

468.382 

9.513.692 

х 10 

4.683.820 

95.136.920 

х 20 

9.367.640 

190.273.840 

х 50 

23.419.100 

475.684.600 


Računato na osnovu podataka koji su preuzeti iz Klirinške institucije banaka Udruženja banaka Srbije 
Za х 1, prosečan broj poruka po danu je 1874, 

Za х 1, prosečan broj transakcija po danu je 38055. 


Tabela 1. Finansijska očekivanja u odnosu na broj poruka na godišnjem nivou 
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Prilog 9: 

Triger nad tabelom stanja. 

Triger nad tabelom Stanja ima zadatak kada se promeni stanje na računu pokuša da 
izvrši još jednu transakciju koja je u bazi podataka zapisana sa stanjem „па čekanju za 
izvršenje zbog nedostatka sredstava“. 

CREATE TRIGGER [dbo] [FirstOnStanja] 

ON [dbo] [Stanja] after 
UPDATEAS 

declare 

@Racun varchar(50), @PocetnoStanje топеу, @ZakljucanCredit bit, @ZakljucanDebit 
bit, @Stanje топеу, @Datum datetime, @Pom integer, @IDTransakcije varchar(50), 
@RacunDugujeTransakcije varchar(30), @RacunPotrazujeTransakcije varchar(30), 
@DatumTransakcije datetime, @IznosTransakcije топеу, @IDPorukeTransakcije 
varchar(50), @Prioritet char(4), @PrioritetTransakcije char(4), StatusTransakcije 
varchar(lO), @MTTipTransakcije char(3), @TRNPorukeTransakcije char(12), 
@TRNDatumTransakcije char(6), @Poruka varchar(50), @StanjeA топеу, @StanjeB 
топеу, @IDPoruke 

varchar(50), @Racunl varchar(30), @Racun2 varchar(30), @PrioritetN int, @MT76 
varchar(72), @MT77A varchar(72), @StatusRGSa varchar(18) 

SELECT @StatusRGSa StatusRGSa FROM BrojPoruke 

if(@StatusRGSa r T) 

BEGIN 

if((select trigger_nestlevel()) < 25) 
begin 

select @Racun Racun, 

@PocetnoStanje PocetnoStanje, 

@ZakljucanCredit ZakljucanCredit, 

@ZakljucanDebit = ZakljucanDebit, 

@Stanje Stanje, 

@Datum Datum FROM inserted 
select @Pom = count(*) 
from Transakcije 

where RacunDuguje @Racun and Status = '20’ 
if(@Pom > 0) 
begin 

select top 1 @Poruka IDPoruke 
from Transakcije 

where RacunDuguje = @Racun and Status '20' 
order by Prioritet, Brojac asc 
select top 1 

@RacunDuguj eT ransakcij e RacunDuguj e, 

@RacunPotrazuj eTransakcij e RacunPotrazuj e, 
@DatumTransakcije Datum, 

@IznosTransakcije Iznos, 

@IDPorukeTransakcije IDPoruke, 
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@PrioritetTransakcije Prioritet, 

@StatusTransakcije Status, 

@MTTipTransakcije MTTip 
from Transakcije 
where IDPoruke @Poruka 
select @StanjeA Stanje 
from Stanja 

where Racun = @RacunDugujeTransakcije and Datum 
@Datum 

select @StanjeA = @StanjeA @IznosTransakcije 

if(@StanjeA<0) 

begin 

select @Prioritet Prioritet from Transakcije where IDPoruke 

@Poruka 

select @Prioritet = substring(@Prioritet, 3, 4) 
select @PrioritetN=convert(integer @Prioritet) 
if (@Prioritet>90) 
begin 

update Transakcije set Status = '99' where IDPoruke 

@IDPoruke 

set @MT76 'Prioritet > 90 i stanje < 0' 
set @MT77A @MT76 

if( @MTT ipTransakcij e= 102) 
begin 

select @TRNPorukeTransakcije s20, 
@TRNDatumT ransakcij e 
substring(s32A, 1,6) 

from MT102Arhiva 

where IDMT102 =@IDPorukeTransakcije 
end 

if(@MTT ipTransakcij e= 103) 
begin 

select @TRNPorukeTransakcije s20, 
@TRNDatumT ransakcij e 
substring(s32A, 1,6) 

from MT103Arhiva 

where IDMT103 =@IDPorukeTransakcije 
end 

if(@MTTipTransakcije=202) 

begin 

select @TRNPorukeTransakcije s20 
@TRNDatumTransakcij e 
substring(s32A, 1,6) 

from MT202Arhiva 

where IDMT202 =@IDPorukeTransakcije 
end 
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ехес dbo MTResponsel96 

@MTTipTransakcij e, @IDPorukeTransakcije 

@TRNPorukeTransakcij e, 

@TRNDatumT ransakcij e 

@MT76 @MT77A 

if (@MTTipTransakcije=T02') 

begin 

update dbo MT102Arhiva 
set StatusP = @MT76 where 

IDMT102 @IDPoruke 
end 

if (@MTTipTransakcije=T03') 
begin 

update dbo MT103Arhiva 
set StatusP = @MT76 where 

IDMT103 @IDPoruke 
end 

if (@MTTipTransakcije='202') 
begin 

update dbo MT202Arhiva 
set StatusP = @MT76 where 

IDMT202 @IDPoruke 
end 


end 

end 

else 

begin 

update Transakcije set Status = '90' where IDPoruke @Poruka 
select @StanjeA Duguje 
firom Stanja 

where Racun = @RacunDugujeTransakcije and Datum 
@Datum 

select @StanjeA = @StanjeA + @IznosTransakcije 
select @StanjeB Potrazuje 
from Stanja 

where Racun = @RacunPotrazujeTransakcije and Datum 
= @Datum 

select @StanjeB = @StanjeB + @IznosTransakcije 
update Stanja set Duguje @StanjeA 

where Racun = @RacunDugujeTransakcije and Datum 
@Datum 

update Stanja set Potrazuje = @StanjeB 

where Racun = @RacunPotrazujeTransakcije and Datum 
= @Datum 

set @MT76 'PLACANJE JE REALIZOVANO’ 
set @MT77A = @MT76 
if(@MTT ipTransakcij e= 102) 
begin 

select @TRNPorukeTransakcije s20. 
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end 

end 

END 


@TRNDatumTransakcije = substring(s32A 1,6) 
from MT102Arhiva 

where IDMT102 =@IDPorukeTransakcije 
end 

if(@MTT ipTransakcij e= 103) 
begin 

select @TRNPorukeTransakcije s20, 

@TRNDatumTransakcije = substring(s32A, 1,6) 
from MT103 Arhiva 

where IDMT103 =@IDPorukeTransakcije 
end 

if(@MTTipTransakcije=202) 

begin 

select @TRNPorukeTransakcije = s20, 

@TRNDatumTransakcije = substring(s32A 1,6) 
from MT202Arhiva 

where IDMT202 =@IDPorukeTransakcije 
end 

ехес dbo MTResponse900 

@MTTipTransakcij e, @IDPorukeTransakcije 

@TRNPorukeTransakcij e, @TRNDatumTransakcij e 

ехес dbo MTResponse910 

@MTTipTransakcij e, @IDPorukeTransakcij e 

@TRNPorukeTransakcij e, @TRNDatumTransakcij e 

ехес dbo MTResponseRoute 

@MTTipTransakcij e, @IDPorukeTransakcij e 

@TRNPorukeTransakcij e, @TRNDatumTransakcij e 

if (@MTTipTransakcije='102') 

begin 

update dbo MT102Arhiva set StatusP = @MT76 
where IDMT102=@IDPoruke 
end 

if (@MTTipTransakcije='103') 
begin 

update dbo MT103Arhiva set StatusP = @MT76 
where IDMT103 =@IDPoruke 
end 

if (@MTTipTransakcije='202') 
begin 

update dbo MT202Arhiva set StatusP = @MT76 
where IDMT202=@IDPoruke 
end 
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Prilog 10: 

Biografija autora 

Slobodan Babić je rođen 22.06.1959 godine u Prijedoru, BiH. Osnovnu školu i 
gimnaziju je završio Beogradu. Na Matematičkom fakultetu u Beogradu je diplomirao 
na smeru Numerička matematika sa kibernetikom 1993 godine. Poslediplomske studije 
upisao je na Tehničkom fakultetu u Boru 2005/06. godine. Magistarsku tezu pod 
nazivom „Razvoj platnih sistema baziranih na IS020022 XML standardu sa osvrtom na 
jedinstvenu evropsku platnu zonu“ odbranio je 2008 godine i stekao akademski naziv 
Magistar nauka u naučnoj oblasti Industrijska infonnatika. Individualni je član tima 
međunarodne organizacije TWIST (The Transaction Workflow Innovation Standards 
Team) za standardizaciju llnansijskih lanaca snabdevanja sa sedištem u Londonu, 
Engleska. Osnivač je Udruženja poslovnih informatičara - IIBA Serbia Chapter u 
Beogradu, ogranka Internacionalnog instituta za poslovnu analizu (IIBA) sa sedištem u 
Torontu, Kanada. 

Po završetku osnovnih studija prvo radno iskustvo kao diplomirani matematičar u 
infonnatici je stekao u “LOLA KORPORACIJI A.D.” na razvoju generalnog 
infonnacionog sistema Korporacije u saradnji sa timom Fakulteta organizacionih nauka. 

U Opštini Cukarica je počeo da radi kao sistem analitičar od 1997 godine gde radi na 
studiji razvoja informacionog sistema opštine, uspostavljanju sigumosnih i drugih 
standarda, vođenju projekta razvoja lokalne mrežne infrastmkture, vođenju i učešću u 
projektima razvoja aplikativnih rešenja za potrebe opštine. 

Nakon toga 1999 godine prelazi u Narodnu banku Jugoslavije gde radi na rešavanju 
„problema 2000 godine“, aplikativnom rešenju za monetami sektor (praćenju tokova 
novca), učestvuje u telu za definisanjc metodologije razvoja informatičkih rešenja NBS 
i komisiji za uvođenje novog sistema platnog prometa. 

U Sagu d.o.o. Beograd prelazi 2002 godine na poslove analitičara i rukovodioca 
projekata za platne sisteme gde inicira razvoj platnih sistema baziranih na SWIFT MT 
[210] i IS020022 [101] sistemima pomka i učestvuje kao poslovni analitičar i 
mkovodilac projekta na razvoju e-Banking i dmgih sistema. 

U Kompaniju Dunav osiguranje a.d.o. prelazi 2010. godine na poziciju direktora 
Sektora za obradu podataka i održavanje. Učestvuje aktivno na projektima uvođenja 
arhivističkog sistema kompanije, sistema za izdavanje polisa autoodgovornosti po novoj 
zakonskoj regulativi kao i na sistemu za evidenciju distribuiranih informatičkih resursa 
kompanije. Trenutno je na poziciji direktora Sektora za sistemsku podršku u 
Infonnatičkoj funkciji Kompanije Dunav osiguranje a.d.o. 
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Prilog 11. 


Izjava o autorstvu 


Potpisani Slobodan N. Babić 
broj indeksa_ 


Izjavljujem 

da je doktorska disertacija pod naslovom 

MODEL INTEROPERABILNOG ELEKTRONSKOG POSLOVANJA PLATNIH 
SISTEMA ZASNOVANIH NA ONTOLOGIJAMA 

• rezultat sopstvenog istraživačkog rada, 

• da predložena disertacija u celini ni u delovima nije bila predložena za dobijanje 
bilo koje diplome prema studijskim programima drugih visokoškolskih 
ustanova, 

• da su rezultati korektno navedeni i 

• da nisam kršio autorska prava i koristio intelektualnu svojinu drugih lica. 


U Beogradu, 


Potpis doktoranda 
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Prilog 12. 


Izjava o istovetnosti štampane i elektronske verzije 

doktorskog rada 

Ime i prezime autora Slobodan Babić 

Naslov rada MODEL INTEROPERABILNOG ELEKTRONSKOG POSLOVANJA 
PLATNIH SITEMA ZASNOVANIH NA ONTOLOGIJAMA 
Mentor Prof. dr Marijana Despotović-Zrakić 

Potpisani Slobodan N. Babić 

Izjavljujem da je štampana verzija mog doktorskog rada istovetna elektronskoj verziji 
koju sam predao za objavljivanje na portalu Digitalnog repozitorijuma Univerziteta u 
Beogradu. 

Dozvoljavam da se objave moji lični podaci vezani za dobijanje akademskog zvanja 
doktora nauka, kao što su ime i prezime, godina i mesto rođenja i datum odbrane rada. 
Ovi lični podaci mogu se objaviti na mrežnim stranicama digitalne biblioteke, u 
elektronskom katalogu i u publikacijama Univerziteta u Beogradu. 

Potpis doktoranda 

U Beogradu,_ 
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Prilog 13. 


Izjava o korišćenju 


Ovlašćujem Univerzitetsku biblioteku „Svetozar Marković“ da u Digitalni repozitorijum 
Univerziteta u Beogradu unese moju doktorsku disertaciju pod naslovom: 


MODEL INTEROPERABILNOGELEKTRONSKOG POSLOVANJA PLATNIH 
SISTEMA ZASNOVANIH NA ONTOLOGIJAMA koja je moje autorsko delo. 


Disertaciju sa svim prilozima predao sam u elektronskom fonnatu pogodnom za trajno 
arhiviranje. 

Moju doktorsku disertaciju pohranjenu u Digitalni repozitorijum Univerziteta u 
Beogradu mogu da koriste svi koji poštuju odredbe sadržane u odabranom tipu licence 
Kreativne zajednice (Creative Commons) za koju sam se odlučio. 


1. Autorstvo 

2. Autorstvo - nekomercijalno 

3. Autorstvo - nekomercijalno - bez prerade 

4. Autorstvo - nekomercijalno - deliti pod istim uslovima 

5. Autorstvo - bez prerade 

6. Autorstvo - deliti pod istim uslovima 

(Molimo da zaokružite samo jednu od šest ponuđenih licenci, kratak opis licenci dat je 
na poleđini lista). 


U Beogradu, 


Potpis doktoranda 
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